Pull to refresh

Comments 51

Про перезапуск демонов при изменении конфига — действиетльно клево. Спасибо.
И вот спустя 11 лет офигенный совет: Предусмотреть автоматичский откат к предыдущей версии, если вдруг новый конфиг кривой (да, да. Ничего не сломается мы только конфиг катим.)
Так это же примеры, а не готовый продукт =). Каждый может сам для себя предусмотреть любой необходимый функционал.
У некоторых сервисов есть классная команда типа configtest, который перезапускает процесс только если конфиг клёвый.
Как раз Dilesoft недавно искал такую штуку!
Ему бы она не подошла (ИМХО), так как для бекапа конфигов требуется гарантированно работающий механизм. А вот поменяли вы конфиги в single-user mode, когда следящий демон не работает — и конфиги не забекапились.

Сейчас в LKML обсуждают новый механизм — fanotify, в который, может быть, будет добавлено «гарантированное» получение уведомлений про изменение файлов (если уведомление не получено сейчас, то оно будет получено при следующем старте демона, возможно даже после перезагрузки).
Ну, это у него надо спросить, подойдет ли…
UFO landed and left these words here
Демон не работает, когда:
* система в single-user mode;
* демон кто-то выключил вручную и ещё не включил обратно (или вообще забыл включить);
* демон упал;
*…
UFO landed and left these words here
Выполняет роль безопачного режима венды. В юниксах в этом ражиме возможен только один пользователь — рут. И как правило не чтартуют никакие службы — ака демоны. Используется при устрвнении аварий, воссьановлении рут пароля и нпример в фрибсд этот режим используют при обноылении системы.
В юниксах в этом ражиме возможен только один пользователь — рут.

Неправда. su sername и вперёд. Можно даже «рассвет вручную» сделать и иксы запустить (сначала hald стартовать, ещё несколько сервисов и startx от юзера).
на файловой системе ntfs-3g — точно не работает =)
для автоматизации репостинга с лепры?
UFO landed and left these words here
А поддерживаются ли исключения?

Скажем, inotifywait я могу дать команду — «следи за /etc, КРОМЕ /etc/udev.d» потому, что бекапить /etc/udev.d (с динамически создаваемыми правилами) мне не нужно.

Вообще, в список «целей» попадает gentoo-переменная CONFIG_PROTECT, а в список «исключений» — переменная CONFIG_PROTECT_MASK
Нет. Такой возможности там нет, к сожалению.
А нельзя как-нибудь отдельно фильтровать? Ну, я просто в танке. :)
Можно, но это же лишняя работа.

Кроме того, есть ещё одно неудобство. Мне-то надо действия выполнять не сразу, а через некоторую задержку. Редактирую я пачку конфигов, закончил — вот тут-то и настало время бекапа. Для этого, видимо, incron не очень подходит, либо с ним нужно искать другое решение задачи.

А вот inotifywait как раз позволяет написать такой shell-скрипт, с ним я задачу решил ;)
grep в целевом скрипте. Фильтруйте — не перефильтруйте :)
Логичнее просто не вешать триггер inotify на ненужные объекты, чем вешать на все и потом следить за тем, нужный или ненужный объект сработал?
Ещё одно соображение. Если в /etc создать поддиректорию — скрипт elve подхватит её и повесит на неё триггер автоматом? А это нужно.
Автоматом повесится. Я проверял
Ок, повестье на /etc/myconfig.conf и не вешайте на /etc/udev.d.
Триггер вешается на inode (отсюда и название, suprise), и против этого не попрёшь.
Ага, клевая штука, используем inotifywait для сбора множества мелких js и css файлов в 2 больших и последующего сжатия. Очень удобно — сохраняешь изменения в любом из мелких файлов, inotifywait отслеживает изменение в указанной директории и поддиректориях, и запускает команду сборки.
UFO landed and left these words here
Кстати в Unix есть подобный механизм, слегка другой правда.
В Widows, тоже, но там идеология сильно отличается.
Оговорка прямо по Фрейду :) «widow» — «вдова» по-английски
Вот, нашёл у себя в исходниках:
man 2 kqueue (для FreeBSD и Darwin)

У меня была идея, написать на python кроссплатформенного демона, реагирующего на такого-рода события, но дальше «ядра» для Windows и Linux дело не продвинулось — времени нет.
Спасибо за топик.

ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.

Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
Тогда можно по закрытию файла делать перезапуск. Это мой простенький пример. Вариаций очень много.
Главная вариация — блокировки надо предусмотреть.
Я вижу интерес к теме имеется. Значит скоро напишу про использование утилит из пакета inotify-tools если, конечно, merlin_rterm меня не опередит =)
Интересная штука.
Только поправьте «$% флаг события (тестом)» — наверное, имелось в виду «текстом».
Большое спасибо. Опечатку поправил.
Штука интересная, но не стоит её использовать для конфигов, стоит подыскать примеры получше.

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

Про запись кусками не думал. У меня маленькие конфиги. Они сразу пишутся =).
> У меня маленькие конфиги. Они сразу пишутся =).
Не стоит на это рассчитывать.

Из примеров — наш админ планирует использовать данную штуку для оповещения изменений конфигов. Т.е. конфиг поменялся -> сообщение на jabber о том кто его его поменял, когда и т.д.
Вообще-то, была другая задумка — автоматический бекап новой версии конфигов в svn. «Нулевая» версия (до запуска сервиса) бекапится руками, а все последующие — автоматом; при желании, в таком архиве можно будет найти любые версии любых конфигов.
Нет защиты от множественного запуска например команды backup при копировании нескольких файлов сразу в /etc
Да. Именно поэтому само копирование выполняется с помощью rsync.
Думаю, что мне удастся реализовать все более красиво с помощью пакета 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. Предлагаю доделать это (наконец) и написать сюда статью.
Кстати это было бы супер — на все свои сервера ставить такую штуку, единый svn/git/hg/bzr реп и мы сразу же видим изменение конфигурации на сервере. Пойду поразбираюсь как бы это на питоне сваять.
Спасибо, написал скрипт, который каждый раз при вставке flash`ки делает резервную копию на жёсткий диск через rsync, теперь не так страшно потерять её :)
Думаю, логичнее было бы сделать это через udev.
Кстати, вместо squid restart Вы бы лучше делали squid -k reconfigure — избежите множества проблем ;)
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.