LINUX.ORG.RU

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


2

1

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

★★★★★

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

Kroz ★★★★★ ()

ах да, ещё ossec

anonymous ()
Ответ на: комментарий от Kroz

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Kroz ★★★★★ ()

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

Novell-ch ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

Kroz ★★★★★ ()
Ответ на: комментарий от Novell-ch

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

megabaks ★★★★ ()
Ответ на: комментарий от Kroz

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

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

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

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

jcd ★★★★★ ()
Ответ на: комментарий от anonymous

samhain

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

jcd ★★★★★ ()
Ответ на: комментарий от RedEyedMan3

debsums

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

jcd ★★★★★ ()
Ответ на: комментарий от hidden_4003

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

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

jcd ★★★★★ ()
Ответ на: комментарий от anonymous

md5deep

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

jcd ★★★★★ ()

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

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

justAmoment ★★★★★ ()
Ответ на: комментарий от jcd

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

hidden_4003 ()
Последнее исправление: hidden_4003 (всего исправлений: 1)
Ответ на: комментарий от justAmoment

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

jcd ★★★★★ ()
Ответ на: комментарий от jcd

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

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

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

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

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

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

Kroz ★★★★★ ()
Ответ на: комментарий от jcd

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

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от Kroz

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

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

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

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

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

jcd ★★★★★ ()
Ответ на: комментарий от justAmoment

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.