Comments 51
Про перезапуск демонов при изменении конфига — действиетльно клево. Спасибо.
Как раз Dilesoft недавно искал такую штуку!
Ему бы она не подошла (ИМХО), так как для бекапа конфигов требуется гарантированно работающий механизм. А вот поменяли вы конфиги в single-user mode, когда следящий демон не работает — и конфиги не забекапились.
Сейчас в LKML обсуждают новый механизм — fanotify, в который, может быть, будет добавлено «гарантированное» получение уведомлений про изменение файлов (если уведомление не получено сейчас, то оно будет получено при следующем старте демона, возможно даже после перезагрузки).
Сейчас в LKML обсуждают новый механизм — fanotify, в который, может быть, будет добавлено «гарантированное» получение уведомлений про изменение файлов (если уведомление не получено сейчас, то оно будет получено при следующем старте демона, возможно даже после перезагрузки).
Ну, это у него надо спросить, подойдет ли…
Демон не работает, когда:
* система в single-user mode;
* демон кто-то выключил вручную и ещё не включил обратно (или вообще забыл включить);
* демон упал;
*…
* система в single-user mode;
* демон кто-то выключил вручную и ещё не включил обратно (или вообще забыл включить);
* демон упал;
*…
Это runlevel 1 :)
Выполняет роль безопачного режима венды. В юниксах в этом ражиме возможен только один пользователь — рут. И как правило не чтартуют никакие службы — ака демоны. Используется при устрвнении аварий, воссьановлении рут пароля и нпример в фрибсд этот режим используют при обноылении системы.
на файловой системе ntfs-3g — точно не работает =)
для автоматизации репостинга с лепры?
А поддерживаются ли исключения?
Скажем, inotifywait я могу дать команду — «следи за /etc, КРОМЕ /etc/udev.d» потому, что бекапить /etc/udev.d (с динамически создаваемыми правилами) мне не нужно.
Вообще, в список «целей» попадает gentoo-переменная CONFIG_PROTECT, а в список «исключений» — переменная CONFIG_PROTECT_MASK
Скажем, inotifywait я могу дать команду — «следи за /etc, КРОМЕ /etc/udev.d» потому, что бекапить /etc/udev.d (с динамически создаваемыми правилами) мне не нужно.
Вообще, в список «целей» попадает gentoo-переменная CONFIG_PROTECT, а в список «исключений» — переменная CONFIG_PROTECT_MASK
Нет. Такой возможности там нет, к сожалению.
Можно, но это же лишняя работа.
Кроме того, есть ещё одно неудобство. Мне-то надо действия выполнять не сразу, а через некоторую задержку. Редактирую я пачку конфигов, закончил — вот тут-то и настало время бекапа. Для этого, видимо, incron не очень подходит, либо с ним нужно искать другое решение задачи.
А вот inotifywait как раз позволяет написать такой shell-скрипт, с ним я задачу решил ;)
Кроме того, есть ещё одно неудобство. Мне-то надо действия выполнять не сразу, а через некоторую задержку. Редактирую я пачку конфигов, закончил — вот тут-то и настало время бекапа. Для этого, видимо, incron не очень подходит, либо с ним нужно искать другое решение задачи.
А вот inotifywait как раз позволяет написать такой shell-скрипт, с ним я задачу решил ;)
grep в целевом скрипте. Фильтруйте — не перефильтруйте :)
Логичнее просто не вешать триггер inotify на ненужные объекты, чем вешать на все и потом следить за тем, нужный или ненужный объект сработал?
Ага, клевая штука, используем inotifywait для сбора множества мелких js и css файлов в 2 больших и последующего сжатия. Очень удобно — сохраняешь изменения в любом из мелких файлов, inotifywait отслеживает изменение в указанной директории и поддиректориях, и запускает команду сборки.
На sudo уже есть, ничего делать не надо:
xkcd.com/838
xkcd.com/838
Кстати в Unix есть подобный механизм, слегка другой правда.
В Widows, тоже, но там идеология сильно отличается.
В Widows, тоже, но там идеология сильно отличается.
Оговорка прямо по Фрейду :) «widow» — «вдова» по-английски
Вот, нашёл у себя в исходниках:
man 2 kqueue (для FreeBSD и Darwin)
У меня была идея, написать на python кроссплатформенного демона, реагирующего на такого-рода события, но дальше «ядра» для Windows и Linux дело не продвинулось — времени нет.
man 2 kqueue (для FreeBSD и Darwin)
У меня была идея, написать на python кроссплатформенного демона, реагирующего на такого-рода события, но дальше «ядра» для Windows и Linux дело не продвинулось — времени нет.
Спасибо за топик.
ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.
Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.
Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
Я вижу интерес к теме имеется. Значит скоро напишу про использование утилит из пакета inotify-tools если, конечно, merlin_rterm меня не опередит =)
Интересная штука.
Только поправьте «$% флаг события (тестом)» — наверное, имелось в виду «текстом».
Только поправьте «$% флаг события (тестом)» — наверное, имелось в виду «текстом».
Штука интересная, но не стоит её использовать для конфигов, стоит подыскать примеры получше.
Кстати очень интересный вопрос как эта подсистема выдаёт MODIFY, ведь операции записи могут идти кусками. Варианты — по закрытию файла или после записи каждого куска…
Кстати очень интересный вопрос как эта подсистема выдаёт MODIFY, ведь операции записи могут идти кусками. Варианты — по закрытию файла или после записи каждого куска…
Пример взят из жизни. Если вы можете предложить что-то более интересное, я буду только рад узнать ваши варианты использования этой программы.
Про запись кусками не думал. У меня маленькие конфиги. Они сразу пишутся =).
Про запись кусками не думал. У меня маленькие конфиги. Они сразу пишутся =).
Вообще-то, была другая задумка — автоматический бекап новой версии конфигов в svn. «Нулевая» версия (до запуска сервиса) бекапится руками, а все последующие — автоматом; при желании, в таком архиве можно будет найти любые версии любых конфигов.
Нет защиты от множественного запуска например команды backup при копировании нескольких файлов сразу в /etc
Да. Именно поэтому само копирование выполняется с помощью rsync.
Думаю, что мне удастся реализовать все более красиво с помощью пакета inotify-tools.
Думаю, что мне удастся реализовать все более красиво с помощью пакета inotify-tools.
Как я делал:
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. Предлагаю доделать это (наконец) и написать сюда статью.
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, теперь не так страшно потерять её :)
Кстати, вместо squid restart Вы бы лучше делали squid -k reconfigure — избежите множества проблем ;)
Спасибо огромное! то что нужно
Sign up to leave a comment.
Inotify или автоматизация рутинных операций с помощью incron