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