> В том случае Михаил Шигорин кого-то озадачил вопросом "предложите что-то конкретное". Я
> предложил. Он так и не ответил. Наверное, решил, что шучу. А может я забыл.Тут что угодно может быть. Он периодически пытается допустим дебианщиков подъ...ть, с потугами доказать что альт типа-лучше. Но дебианщики так то умеют проблемы решать и по факту обычно оказывается если не тот, то альтернативный способ как нечто делать, и он тоже работает, в результате демо получается неубедительным.
> К примеру, нажал я в mc на каком-то подкаталоге из /usr "удалить"
> и потом "ввод". Что будет дальше у Редхата и Дебиана?
1) Нормальные люди под рутом в общем случае не сидят. Поэтому, в 99% случаев будет -EPERM от системы на подобные потуги.
2) Если вдруг я ну вот лох-лох, не выспался там, и под рутом все же вот это влупил - ну, это печально, однако все что мне грозит это ребут в rootfs или, если совсем уж все плохо (например /boot снес) - бут с флешки. А дальше - очень небольшое жонглирование с снапшотом - и вот уже OS опять на месте. Минуты за две. В примерно том виде как была. Заведомо логически консистентном. Как максимум это может быть немного устаревшим вариантом, ему может быть надо апдейты опять накатить или переделать недавние изменения конфигов (все важные изменения логично снапшотить).
И да, это все не пакетный менеджер а ФС обеспечивает. У нее это лучше получается. Заодно в принципе есть и некий список "недавних изменений". И лично я спер идею убунтуев, когда есть уровень менеджмента, он на 1 уровень выше /. Его в нормальном виде не видно, но при желании моунтабельно - и оттуда как раз можно снапшотами порулить.
> А если удаляем ld-linux.so?
initrd оно так то будет похрен, а операционка на флехе даже и выпиленый /boot вернуть может.
> Или же кто-то наконец скомпилировал Z0mbie.Mistfall под Linux,
> когда мы узнаем о факте заражения?
Надежнее всего бутанув с readonly носителя отдельную копию операционки, конечно, заведомо нормальную. Потому что если в ОС подозрение на руткит, доверять ей уже не стоит.
От некоторых развеселых экспонатов даже это не поможет. Вон тот хайтек патчащий фирмвари винчей и отдающий "не те" сектора плевать хотел. Однако, кмк у именно меня он "почему-то" облажается в парсинге, а я озадачусь вопросом WTF. Что такое JTAG я, таки, знаю. Так что в этом случае ценный экспонат, вероятно, улетит всем мыслимым аверам, для максимизации урона. Сделать невкусным соотношение gain/loss для атакующего - кажется мне удачной идеей.
> Всё это в принципе может решать "пакетник",
ИМХО, это все же не его задача. ФС со снапшотами это может делать намного фундаментальнее, куда меньше зависит от живости ОС и ее начинки - а менеджмент системы при этом начинает напоминать привычные виртуалки, с теми же терминами и свойствами вместо очередного наколенного кастома.
> поскольку именно у него есть вся необходимая информация,
В принципе да, НО...
1) Уметь repair снесенного usr значит что он должен хранить все скачаные архивы. Плюс 100500 к жрачу места системой на хранение полных архивов.
2) Ах да, снапшоты имеют интересную фичу: core set блоков только один, место занимает только "дельта". Если эту концепцию понять, потом все просто, логично и эффективно. И это понимают все кто продвинуто работал с виртуалками.
3) Пакетнику для работы нужна рабочая система. Он обычная программа. Конечно, можно его статически отстроить и проч. Но тогда фиксить его сам станет отдельной канителью для майнтайнеров с трекингом внутренних либ и дублированием его сущностей. Можно наверное в initrd положить. Но это порядком увеличит initrd - и это НЕ есть консистентное состояние: оно еще зависит от файлов с статусом пакетов и проч описывающими что установлено и т.п..
4) А продолб этого состояния в системе с пакетником так то довольно неприятный опыт. Снапшот что, он пакетник и его состояние синхронно откатит в взаимно-консистентное состояние. Врядли кто снапшотил уже порушеную систему.
5) Full reinstall всего что было в usr займет неиллюзорное время сравнимое с полным инсталлом системы. Именно поэтому продвинутый народ оперирует "образами", "снапшотами", "send" и тому подобным. Так тупо в цать раз быстрее. Откат снапшота не ворочает большую часть блоков, только указатели переставляет в вид когда теперь это прошлый view. А пакетник, таки, будет все 100500 гигабайтов телепать от и до.
6) В как минимум дебиановском пакетнике можно повесить хук делающий что угодно после инсталла пакета. В том числе и снапшот можно сделать. Нужно ли - вопрос номер два.
7) Side effect of CoW: "копирование" виртуалки с 20Гб диском, или даже образа винча на 2 терабайта чтобы "fsck" на нем прогнать занимает примерно секунду, и нового места это не занимает. Это тоже частный случай "unshare", но в этом случае блоков ФС: копия изначально референсится на те же блоки, по мере расхождения CoW делает свое дело. Только он это делает плавно. И те цать блоков которые fsck изменил "в run time" меня не парят как "занимаемое место". В отличие от идеи копировать 2 терабайта по настоящему. А видимость независимой копии, вот, есть. Конечно как и в случе с VM дельта может отрастать, если это не контролировать.
> под "целостностью системы" некоторые понимают удовлетворение зависимостей пакетиков,
Целостность системы весьма многогранный аспект. Есть еще допустим логическая консистентность: данные и конфигурация должны соответствовать бинарям. Ну вот представляете, автор может допустим формат конфига поменять в энной версии. У вас был старый usr, старый конфиг. Потом после апдейта пакета вы пропатчили конфиг. Стал новый usr, новый конфиг. Но если откатывать абы как, можно получить скажем новый usr/старый конфиг. И оно таки сломается. А когда после дурного отката это сделают цать программ сразу, станет интересно.
> а под "удовлетворением зависимостей" - присутствие записи в БД, а не
> наличие валидных файлов.
Полная фактическая верификация, видите ли совершенно не бесплатная по скорости операция, чтобы ее при обычном инсталле пакета ворочать. Ну то-есть да, при желании что-то такое сделать можно, но тормозило бы оно дико. Поэтому как максимум имеет смысл отдельной утилсой или опцией чекера выделенного под такую задачу.
Более того - у MSI на вот подобной почве бывает неиллюзорное горе от ума.
- Инсталлю это, это и это...
- Ой, не получилось, давай-те ка я rollback сделаю!
- Упс. Оказывается, файл роллбэка или исходник пакета были повреждены. ERROR! FAIL! ПОЛУНДРА!11
В чем проблема? В такой системе вообще ничего не ставится и не удаляется. И черт его знает как это вышибить кроме как реинсталлом системы. Это то что вы получаете за идиотскую оверинженерию пакетника. Он становится тормозным, хлипким, и потом оказывается что те задачи лучше и консистентнее решались на других уровнях вообще.
Вариант для распечатки
