Секретный нетбук

asus eee 901 с intel atom + внешний usb-диск?

м.б.
Только хотелось не внешний диск

нетбук

диск не менее 100 – 120 ГБ.

Только хотелось не внешний диск

А чтоб считал быстрее кластера не хотите? Есть субноуты типа тошибы портеж, на них ставится Linux если что, но стоимость порядка 100-150k.

Просто для нынешний времен 100 ГБ это почти ничего... Большая флешка.
А 20 ГБ примерно равно 0 (-:

Просто для нынешний времен 100 ГБ это почти ничего

Только если загадить диск HD-фильмами. Для работы (а тема мне подсказывает, что машина нужна не для игрушек) это более, чем достаточно.

Купил вышеуказанный ноут, установил Debian с шифрованным LVM.
Если я захочу менять разделы, что я должен делать? Например, там автоматически установилось /tmp как раздел, я же хочу его монтировать в ОЗУ в виде tmpfs.
Как я понял, там два физ. раздела – /dev/sda1 – где /boot, и /dev/sda2 – где lvm (как и при обычном lvm), только второй физ. раздел (не логические?) зашифрован dm-crypt.
Т.е. я могу менять разделы lvm как при работе с обычным lvm, или я должен учитывать как-то это шифрование?

Т.е. я могу менять разделы lvm как при работе с обычным lvm, или я должен учитывать как-то это шифрование?

Шифруется по умолчанию, емнип, DOS'овский раздел, и как потом поверх него будут нарезаны "вторичные разделы" lvm'у пофиг.

я же хочу его монтировать в ОЗУ в виде tmpfs.

Отредактируйте /etc/fstab

Аккуратнее, а то потеряете данные. В /etc/cryptab прописано, что и как зашифровано. Если зашифрован физический том, то все логические тома в нём зашифрованы и не видны "снаружи", их можно двигать внутри него как угодно набором утилит LVM. Если зашифрованы логические тома (кстати можно совместить шифрование логических томов по отдельности внутри физического, если не критично для производительности), то надо учитывать шифрование.

В /etc/cryptab прописано, что зашифрован физический диск /dev/sda2.Значит, я могу спокойно играться с обычными утилитами LVM?
P.S. Какие могут быть проблемы с безопасностью при том, что /dev/sda1 не зашифрован? И вообще, реально ли зашифровать раздел, с которого грузишься? (Будет ли грузиться после этого система?). Или для большей безопасности можно только использовать раздел, на котором размещен /boot, на съемном носителе?
P.P.S. В случае, если зашифровать логические тома, возможно ли изменение размера разделов без потери данных? Или в любом случае надо копировать на внешний носитель, менять размер и копировать обратно?

Подмена ядра, стартового рамдиска на троянские версии, сливающие пароль, но это значит, что у противника уже есть доступ к компьютеру.

Говорят GRUB2 такое поддерживает, но это IMHO бессмыссленно, т.к. можно инфицировать сам загрузчик (GRUB2), так, чтобы он тоже сливал пароль.

Только так, если предполагается, что носитель всегда при себе, а компьютер — нет. Но могут ведь и BIOS, и аппаратную часть протроянить при физическом доступе.

Возможно, особенно в сторону увеличения. Dmcrypt специально для этого был написан с прицелом на тесную интеграцию с LVM. Простой пример. Народ часто жаловался на траблы с потерей данных, но на своём опыте не сталкивался.

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

и /dev/sda2 – где lvm (как и при обычном lvm), только второй физ. раздел (не логические?) зашифрован dm-crypt.

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

Так можно обойтись и без бэкапов на внешний носитель, хотя и они не помешают.

Нет, это крайне ненадёжно. Если носитель сломается, то полетит всё, что на нём – хрестоматийный пример с фэйлом, который систематически воспроизводится админами. Бэкап – только на сторонний носитель.

Речь только о бэкапе на момент изменения логических томов. А для систематических бэкапов — да, внешний.

А стоит при том, что диски криптованные, монтировать /tmp в ОЗУ? Тем более что она всего – 1 гиг (ну, можно еще модул в 1 гиг установить, правда).
Или лучше сэкономить на ОЗУ, все равно к /tmp враг сможет добраться только взломав криптование диска?

А стоит при том, что диски криптованные, монтировать /tmp в ОЗУ? Тем более что она всего – 1 гиг

Нет, но это актуально, если /tmp не шифруется или памяти более чем достаточно (может увеличить скорость работы с системой).

Если кому-то необходимо работать с ооочень большими /tmp и swap (в которых оседают гигабайты данных), то можете завести для них логические разделы и прописать в /etc/cryptab что-то вроде (сверьтесь с man по своему дистрибутиву):
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512 tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512
Тогда эти тома будут перешифровываться и подниматься каждый раз после перезагрузки на рэндомном ключе и на них будет заново производиться mkfs (это не так медленно как можно подумать).

Теперь в /tmp можно симлинками вынести всё временное (только осторожно, при создании каталогов в /tmp существуют жёсткие правила безопасности по правам, случайным именам, "атомарности" операции создания), что необходимо удалять при выключении (перезагрузке). Гибернация естественно работать не будет.