Демон проверки целостности данных на ФС

samhain

cron?

cron + http://sourceforge.net/projects/tripwire/

md5deep

А смысл? Контроль целостности происходит на уровне HDD, SMART в попощь. Приведи пример когда этого недостаточно.

ах да, ещё ossec

подмена бинарника кулхацкером с бэкдором

Ошибка в софте/железе до hdd.

zfs

подмена бинарника кулхацкером с бэкдором

. . . для чего будет вызвана соответствующая функция записи из ядра, и не то, что данные, там целостность фс не повредится. Ибо будет выглядеть как обычное изменение файла.

rpm умеет выводить список измененых файлов после установки.

Ошибка в софте/железе до hdd.

Там только память и SATA контроллер. В первом случае, если это так важно, ставьте DDR с ECC, во втором случае все равно отлавливается; сам сталкивался с битыми SATA шнурками сыпет сообщения в лог ядра плюс в SMART'е один счетчик увеличивался (уже не помню название).

Еще варианты?

так все пм умеют или предоставляют всё необходимое для этого сторонним сфотинам

А смысл? Контроль целостности происходит на уровне HDD, SMART в попощь

1) смарт никак не сигнализирует пользователю о ремаппинге

2) ремаппинг происходит при попытке обращения к сбоящему сектору. если сектор побился и при этом к нему давно не обращались - он так и будет лежать испорченным и я не буду об этом знать

3) какой-нибудь дурацкий или вредный софт, или даже моя собственная невнимательность

debsums

samhain

больно сложное и комплексное решение, мне бы чего попроще

debsums

речь не о пакетах, а о данных. тем более, причем тут deb?

cron + http://sourceforge.net/projects/tripwire/

неплохо, попробую. хотя по ссылке народ ругается, что эта штука дескать сильно ест процессор, что не особо-то желательно

md5deep

почти оно, я хотел накидать скипт на основе этой штуки

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

git любит смотреть на себя, когда работает, а потом рассказывать «что, да как». Ну, и ты посмотри как git работает.

тогда еще + ionice, или nice, хотя в диск должно упереться раньше чем в процессор.

мне нужно относительно готовое решение, а не совет, как навелосипедить своё.

Aide

то, что нужно. спасибо!

1) смарт никак не сигнализирует пользователю о ремаппинге

В SMART есть така штука как «Reallocated Sectors Count» который говорит именно об этом. А сигнализация пользователю - задача соотв. софта, вариантов масса.

2) ремаппинг происходит при попытке обращения к сбоящему сектору. если сектор побился и при этом к нему давно не обращались - он так и будет лежать испорченным и я не буду об этом знать

А здесь по-другому даже теоретически невозможно. Если ты там что-то такое важное хранишь, проверяй периодически, делай бекапы, организовывай raid'ы. Ваш К. О.

3) какой-нибудь дурацкий или вредный софт, или даже моя собственная невнимательность

Тогда тебе никакие автоматизированные системы не помогут. Ну представь, ты изменил файл: как система узанает, ты это специально или «по невнимательности». Самое лучшее решение, которое я нашел, - offline backup. Ну, то есть раз в месяц/полгода ты зеркалишь свой hdd на другой hdd каким-нибудь rsync'ом. Вручную, чтобы система по ошибке твою «невнимательность» не засинхрила. Еще альтернатива - снепшоты, которые есть в zfs и drdb. Я сам из-за этого функционала жду drdb. Правда, ИМХО, снепшоты хороши только для бекапа системы перед апгрейдом; а для данных - лишь rsync с последующим отсоединением HDD от шины питания дабы уберечь от сгорания блока питания.

Да, от невнимательности и вредного софта в определенной мере спасает снятие аттрибута записи и вообще установка грамотных прав доступа. У меня 99% моих данных - read-only. От кулхацкеров не спасет, а вот от случайного delete и незапланированного save частенько спасает.

ну раз смарт-основанные решения не подходят, то зачем их рассматривать?

Ну представь, ты изменил файл: как система узанает, ты это специально или «по невнимательности»

никак, вручную обозревать вывод diff-а в этом случае - неизбежное занятие

Самое лучшее решение, которое я нашел, - offline backup

бэкапы - отдельная область. кстати их целостность можно очень легко мониторить реквестированными мной тулзами

tripwire

git любит смотреть на себя, когда работает, а потом рассказывать «что, да как»

чсв как у создателя