А у них есть решение для кластера? Что оно умеет?
>"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение. Ну, это фактически то же самое, что линковаться со своими open() и так далее. Всё равно остаётся проблема подсовывать это всем в env или патчить ld. Ну и проблема с количчетсвом логов и правами на них.
>Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же. Действительно, sys_call_table больше не экспортируют :( Получается, остаются только совсем сумасшедшие кривости.
>Уверен. Я вам что хочу сказать - хостинг == надежность или хостинг != надежность? Ну можно научиться обрабатывать журнал ФС, там эти изменения хранятся, не в том виде, конечно, не в удобоваримом. Да, именно... Модуль - правильнее. Легче != правильнее.
Журналируемая ФС не записывает все происходящие изменения. То, что она записывает не имеет какого-то API и соглашений - всё остаётся на совести реализации. Так что перешли с ext3 на jfs или ext4 - переписываем нетривиальный модуль.
Увы, с manager'ом ничего не получится придумать - он берет конфигурацию ввв-доменов из конфига апача.
nginx можете переделать, создав в нём один какой-нибудь левый виртхост вроде
server {
listen 80 default;
location @backend { proxy_pass http://127.0.0.1; }
location / { proxy_pass http://127.0.0.1; }
location ~ регексп_из_исп { root /var/www/symlinks/$host; error_page 404 = @backend; }
}
[irony]
пишите нужно смотреть
[/irony]
inotify умеет следить только за одной папкой. В частности, это значит, что придётся в ядре хранить по несколько десятков байт для каждой папки и при запуске - сканировать всю ФС.
И все сутки у Вас получается снижена производительность :(
:(
Способы перехватить сисколлы в Linux:
1) Линковка со своим open(), close() и так далее. Обходится. Сложна в компиляции - абсолютно всё нужно слинковать с другими библиотеками. Процесс, выполняющийся от пользователя, должен уметь писать в общий лог, либо нужно уметь собирать кучу логов.
2) ptrace на все процессы. Съест, наверно, 30-40% Вашего cpu на анализ и на лишние шесть переключений контекста на каждый сисколл.
3) Модуль ядра. Получается то же самое, только длиннее и неудобнее - нужно подставляться в таблицу сисколлов и получать то же самое в итоге.
Вы уверены, что понимаете, зачем есть журналируемые ФС?
Ну всё равно получается минимум - ребут в месяц. Это заведомые 5 минут дауна в месяц, что достаточно плохо.
Плюс, скорее всего, при тестировании на продакшене вылезет что-то достаточно нехорошее, что потребует ещё 5 минут перезагрузки.
Осознание этого в основном и останавливает от использования подобных фич на более-менее серьезном проекте. Хотя, может быть, начальство когда-нибудь созреет до необходимости инноваций.
Кроссплатформенно - это когда волшебные числа берутся из заголовков :)
gfs (не от гугля, а от редхета)
Спокойствие - это "пересобирание ядер по 4 раза за ночь потому что эффект всегда получается немного не тот"? :) Баланс всё-таки нужно соблюдать, хотя мне действительно намного ближе инновационная система ведения техники, чем legacy.
