Pull to refresh

Как и почему следует разбивать диск в никсах

Reading time 3 min
Views 63K
Один из довольно частых вопросов на различных околониксовых ресурсах — вопрос о том, какую схему разбивки дисков использовать. С виду простой вопрос на самом деле таит в себе множество подводных камней. Если, конечно же, дело касается серверов. На десктопах все гораздо скучнее и серее.

Универсального решения в данном вопросе нету, просто есть некоторые аспекты, которыми следует руководствоваться при выборе схемы разбивки.


Ограничение пользователей

Все разделы, куда обычный пользователь имеет права на запись (/home; /tmp; /var/tmp), необходимо вынести в отдельные разделы. Этим шагом убиваем сразу целое семейство зайцев:
  • при переустановке системы нет необходимости впопыхах переносить данные пользователей на другие носители / восстанавливать что откопалось из протухших бэкапов годовалой давности
  • получаем возможность монтировать данные разделы с noexec, чтобы злостные кулхацкеры не запускали всякую дрянь в вашей системе. напомню, что noexec не спасает от шелл скриптов.
  • спасаемся от hard-link атаки (это когда обнаруживается уязвимость в каком-либо пакете, вы его успешно сносите, а уязвимость остается, потому что злоумышленник создал хард-линк на уязвимый файл). Тут и тут можно почитать подробнее.
  • можем использовать в /tmp файловую систему ext2 (журналирование здесь ни к чему, т.к. в случае сбоя восстанавливать ничего не нужно)
Защищаем систему от отказа в работе из-за нехватки дискового места

Стоит помнить, что у нас есть замечательный /var/log, который очень любит забиваться логами под завязку, ненасытные пользователи, которым вечно не хватает дискового пространства и временные папки, которые любят забиваться миллионами временных файлов, которые никто не удаляет. Все подобные разделы (/var; /home; /tmp) так же желательно вынести за пределы корня.

Палки в колеса злоумышленникам

Весьма сомнтельная мера, однако не раз встречал подобную рекомендацию: монтировать /usr в readonly.
Однако самим себе мы так же создаем некие неудобства: обновить то систему так просто теперь не получится. Однако, например в GNU/Debian это обходится добавлением в /etc/apt/apt.conf:
DPkg
{
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};

Правда post-invoke не всегда срабатывает. Иногда приходится с помощью lsof +L1 вычислять кто же виноват, в том, что /usr занят и не может быть перемонтирован в ro.

swap. Нужен или нет?

Сплошь и рядом рекомендации делать своп равным двойному размеру оперативной памяти. На серверах, где бывает и по 64-128Гб (а то и больше) оперативки это даже как то глупо звучит. Особой нужды в свопе на системах нынче нет. Ну только если вы не хотите использовать hibernation. Впрочем это прерогатива ноутбуков, а не серверов.

Опции монтирования

Весьма важный пункт, на который стоит обратить внимание. Помимо вышеупомянутого noexec, на пользовательских разделах стоит ставить nosuid и nodev. Так же можно снижать нагрузку на диск с помощью опций noatime или relatime и с помощью увеличения времени коммита commit=60 (по умолчанию время коммита — 5 секунд).

Итоги

Данные аспекты носят рекомендательный характер, строгих правил по данному вопросу нет. Все зависит от личных предпочтений.
Однако, все же хотелось бы подвести некую черту:
  • Старайтесь выносить из корня в отдельные разделы /boot, /home, /tmp, /var.
  • Используйте lvm, чтобы в дальнейшем не кусать локти, если вдруг какой-то раздел срочно необходимо увеличить.
  • Не забывайте про опции монтирования, щадящие диски. Мы же не хотим, чтобы они вылетали.
  • не забывайте убирать резерв для рута на вынесенных разделах, т.к. в нем более нет необходимости (tune2fs -m 0 /раздел)
Tags:
Hubs:
+190
Comments 141
Comments Comments 141

Articles