@MSGID: 2:5020/570.1 6a45724a
@REPLY: 2:5020/570.1 6a317449
@PID: GED-NSF+LNX 1.1.5-b20110208
@CHRS: CP866 2
@TZUTC: 0300
Привет тебе, All!

Kaк-тo нa дняx (16 июн 26) Dima Krylov пишeт к All...

  [ ... ]


 DK> Сервер на узеле 2:5020/570 упал. Окривел внутренний фаервол и iptables
 DK> заблокировал сам себя. Моих знаний в линуксе для самостоятельного
 DK> исправления ситуации не хватает. iptables -X и вообще все попытки
 DK> взаимодействия с iptables сводятся к ругани на инициализацию и просьбе
 DK> на обновление.
 Я живой, но пока сложности продолжаются. Если кратко, то эта хрень
хранит правила фаервола в файлах

ipsec.conf
ipsec_allow.conf
ipsec_deny.conf

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

 Удалять надо в боевой конфигурации не перегружаясь, лезть в админку
и дезейблить фаервол штатными средствами через WEB-интерфейс.

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

 Я же умный, я "разломал" рейд и ковырял один диск из зеркала в
надежде сохранить возможнось отката на случай совершенно полного краха. Hо
это не помогло и крах случился. Я не сразу заметил, что в результате
моего ковыряния "поплыла" файловая система и после восстановления сетевого
доступа я радостный пихнул в ребилд второй диск, получив консистентные данные
с мусором в папке /ftn/fileecho (пока обнаружено только там, а вот
если косяк будет замечен ещё где-то, то уже точно настанет "всего
хорошего". (c)


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

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

Hапример в

 fileecho/z2pnt/Z2PNT.Z70 вместо архива с нодлистом открывается кусок
какого-то тика из XPICCAT, которого там точно быть не должно.

File Q6VKR.JPG
Area XPICCAT
Desc <3.1> -А запах!.. (927x695) [9.01.02]
Origin 2:5053/51
From 2:5020/715
Size 166620


 Hекоторые файлы не пострадали, где-то вместо files.bbs какие-то
бинарники лежат. Вот вам и ext4. Проследить закономерность мусора я пока не
могу и понять, что или кто мог так перемешать данные - тоже. Пока
продлжаем наблюдение, но возможно всё.

 Отдельная благодарность Oleg Artemjev 2:6078/80.1354. Олег откликнулся
на мой SOS, отложил свои дела и поперся на другой конец города
ковырять мои конфиги. 
При его участии я снова тут. Олег, спасибо.

* Оригинал написан в altyn.local
* Скопировано в n5020.sysop

--- GoldED-NSF
 * Origin: ... паясничать в altyn.local (2:5020/570.1)
SEEN-BY: 452/28 455/19 469/122 4500/1 5001/100
5019/40 5020/101 290 378 400
SEEN-BY: 5020/545 556 570 715 806 830 837 843
848 921 1042 1146 1668 2179
SEEN-BY: 5020/2992 3452 4096 4441 5452 5480 8912
9696 12000 5022/2 5023/24
SEEN-BY: 5030/1081 5034/13 5051/44 5053/58 5055/73
5057/19 5075/128 6035/3
SEEN-BY: 6078/80
@PATH: 5020/570 715 4441