Не без этого, но реальный мир это реальный мир, и не я это решение принимал. Как бы там ни было головной боли добавится, хотя бы заново тестировать плейбуки, которые поверх ожидаемого /tmp добавляли маунтпоинты tmpfs, куда SSSD (чтоб в линукс через LDAP-учетки ходить) складывал свои временные файлы. И не ожидал их потери через 10 дней )). by design он их и так в подкаталоги /tmp/* складывал
Ну как, некоторые приложухи могуть иметь привычку в /tmp что-то большое распаковывать, и не всегда убирать за собой. Так что либо память будет этим забита, либо место кончится и своп будет использоваться (если он есть), либо через 10 дней оно удалится (как настроили дебианцы) и приложение чего-то не найдет (много любит в tmp сыпать bitbucket и жира вроде).
last ну это просто удобно смотреть кто последний на сервере хозяйничал
nodatacow должен отключать чексуммы и сжатие, он и compress взаимоисключающие флаги (можно проверить при помощи compsize). Точнее применится только последний из них (смотреть в findmnt). edit: лучше compress-force, на дистрибутиве debian разница ощутимая
Кажется, придумал оптимальный вариант - SSH MITM. Ключи dropbear есть с открытого раздела, и более того, однажды помогал коллеге восстановить пароль сохраненный в SecureCRT похожим образом. Там правда фингерпринт хоста изменился, но этого нам и было надо. А так просто логировать и перенаправлять весь ввод в SSH. profit
А точно это учитывает обе EFI партиции dpkg-reconfigure grub-efi-amd64? КМК активную замаунченную только. В продуктах Proxmox для этих целей используют специальные хуки (ими заведует proxmox-boot-tool)
Всмысле ФС виртуалки нецелесообразно? Гипервизора то как раз может и целесообразно, если хостинг хочет защитить данные своих клиентов. В общем любимый Proxmox позволяет делать снапшот с памятью из коробки, для восстановленной виртуалки будет выглядеть так что она и не останавливалась. А раз позволяет Proxmox, то любая QEMU-KVM виртуализация тоже технически позволит это сделать
Если это VPSка/VDSка, а не физический хост, все многократно упрощается - как с "заморозкой чипов" так и с анализом незакриптованного раздела. Так-то админ гипера просто делает клон всей машины вместе с RAM-state и исследует сколько хочет.
Если ввод пароля происходит по SSH, то поидее ничего не мешает подшаманить этот незакриптованный dropbear-initramfs загрузчик. Но тут дальше нюансы что метод не 100%. Писать обертку тоже в первом приближении трудоемко (которая будет прозрачно передавать пароль для последующего анлока/проверять успешность), а первые несколько паролей для анлока можно преднамеренно вводить неправильно (когда подшаманенный загрузчик просто принимает пароль и разрывает коннект например)
Кажется, в случае ZFS это только для читаемости полезно чтобы не морочиться потом какой же диск менять. Каждый девайс всеравно получает внутренний цифровой GUID, можно посмотреть через zdb
wechat, если получится зарегистрироваться с симки РФ. Партия выдать социальный рейтинг
Не без этого, но реальный мир это реальный мир, и не я это решение принимал. Как бы там ни было головной боли добавится, хотя бы заново тестировать плейбуки, которые поверх ожидаемого /tmp добавляли маунтпоинты tmpfs, куда SSSD (чтоб в линукс через LDAP-учетки ходить) складывал свои временные файлы. И не ожидал их потери через 10 дней )). by design он их и так в подкаталоги /tmp/* складывал
Ну как, некоторые приложухи могуть иметь привычку в /tmp что-то большое распаковывать, и не всегда убирать за собой. Так что либо память будет этим забита, либо место кончится и своп будет использоваться (если он есть), либо через 10 дней оно удалится (как настроили дебианцы) и приложение чего-то не найдет (много любит в tmp сыпать bitbucket и жира вроде).
last ну это просто удобно смотреть кто последний на сервере хозяйничал
/tmp и last/lastb это они засаду подготовили
nodatacow должен отключать чексуммы и сжатие, он и compress взаимоисключающие флаги (можно проверить при помощи compsize). Точнее применится только последний из них (смотреть в findmnt). edit: лучше compress-force, на дистрибутиве debian разница ощутимая
В Halo уже давно предсказали, а может и в симпсонах тоже. https://www.halopedia.org/Mendicant_Bias
Так он не изменится поидее, приватный ключ dropbear сервера в незашифрованном разделе добывается
Кажется, придумал оптимальный вариант - SSH MITM. Ключи dropbear есть с открытого раздела, и более того, однажды помогал коллеге восстановить пароль сохраненный в SecureCRT похожим образом. Там правда фингерпринт хоста изменился, но этого нам и было надо. А так просто логировать и перенаправлять весь ввод в SSH. profit
Круто. Кому интересно как устроены подобные штуки внутри => https://www.youtube.com/watch?v=AptJJsO5qCg . Там еще много всякого проприетарного железа разбирают
Как говорили когда-то на форумах авто.ру - "топик+ник" :D
По памяти, а если отключить ARC либо настройками, либо проще primarycache=metadata secondarycache=metadata?
А точно это учитывает обе EFI партиции
dpkg-reconfigure grub-efi-amd64? КМК активную замаунченную только. В продуктах Proxmox для этих целей используют специальные хуки (ими заведует proxmox-boot-tool)А-а, понял Вас. Я скорее о прочитанных выше опасениях автора думал, и привычку шифровать диски, т.к. у админов гипервизора слишком много возможностей.
Всмысле ФС виртуалки нецелесообразно? Гипервизора то как раз может и целесообразно, если хостинг хочет защитить данные своих клиентов. В общем любимый Proxmox позволяет делать снапшот с памятью из коробки, для восстановленной виртуалки будет выглядеть так что она и не останавливалась. А раз позволяет Proxmox, то любая QEMU-KVM виртуализация тоже технически позволит это сделать
Если это VPSка/VDSка, а не физический хост, все многократно упрощается - как с "заморозкой чипов" так и с анализом незакриптованного раздела. Так-то админ гипера просто делает клон всей машины вместе с RAM-state и исследует сколько хочет.
Сам не понимает, если речь про кэш на чтение, то это L2ARC называется
Посмотрел на то как фактически разблокируют, отзываю свой коммент о трудоемкости, zfsunlock оказался вообще шелл скриптом ))
Если ввод пароля происходит по SSH, то поидее ничего не мешает подшаманить этот незакриптованный dropbear-initramfs загрузчик. Но тут дальше нюансы что метод не 100%. Писать обертку тоже в первом приближении трудоемко (которая будет прозрачно передавать пароль для последующего анлока/проверять успешность), а первые несколько паролей для анлока можно преднамеренно вводить неправильно (когда подшаманенный загрузчик просто принимает пароль и разрывает коннект например)
Кажется, в случае ZFS это только для читаемости полезно чтобы не морочиться потом какой же диск менять. Каждый девайс всеравно получает внутренний цифровой GUID, можно посмотреть через zdb
Я бы отправил тоже самое, запихнув в doubletracelogs.zip , с припиской kindly do the needful