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

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

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


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

    Все разделы, куда обычный пользователь имеет права на запись (/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 /раздел)
    Share post

    Similar posts

    Comments 141

      +5
      Сейчас решил поднять свой сервер, как раз думал
      как разбить диски, и вы как чувствовали что мне надо))
      Автору огромное спасибо!
        +2
        Хабр следит за ходом наших мыслей. Сам не раз замечал.
        0
        Свопа в два гига всю жизнь хватало…
          +23
          Свопа в 0 байт хватает последние года четыре.
            0
            Сейчас компилирую C++ gSOAP-связки для самописного клиента VMware ESXi (исходник 60 Mb): все 4 Gb RAM забиты до отказа, swap на 8 Gb забит на половину…
              +14
              Это всего лишь повод потратить 1000р на дополнительную память. Но не повод хрустеть диском.
                0
                не всегда. Все зависит от условий. Вот top на моем сервере:
                Mem: 98868808k total, 96339528k used, 2529280k free, 176096k buffers
                Swap: 52428792k total, 311080k used, 52117712k free, 41614092k cached
                если бы не было свопа, то он бы падал по 5 раз в сутки.
                  +3
                  А со свопом оно зависает 5 раз в сутки. Согласен, хорошая альтернатива. Но это не отменяет добавление памяти.
                    +1
                    Диск добавить иногда ощутимо дешевле, чем память. У нас есть машины, где все банки под память уже заняты, а одна плашка в два раза больше, чем была, стоит больше, чем весь рабочий рейд из 10 винтов. А их парой менять.
                    Выделить 16 гигов под своп из терабайта для успокоения oom-killer, этого никто не заметит даже.
                    Если все становится плохо, инсталлируем новую железяку, что не быстро и требует разного рода длительных согласований. Со свопом 0 байт могут быть ощутимые проблемы.
                      +3
                      Если места под память нет — другое дело. Но своп идеологически — костыль, это очевидно.
                        0
                        Когда как. Иногда не костыль, а то без чего не получается работать. Встречались нам расчетные задачки, которые при запуске пытаются у системы отожрать 16 гиг, а реально стоит только 8. При том, в работе задача реально не использует больше половины запрошенной памяти. RHEL4 при таком поведении софта тупо склеивает ласты в kernel panic. Покупать память ради того, чтобы задача могла нормально запросить нужный объем и потом его реально в расчете не использовать, немного неразумно, особенно с учетом цены плашек для серверов. В данном случае не уверен, что это костыль :)
                          0
                          Это костыль в третьем поколении ) Точнее тупые программисты, но это отдельная тема. Я про саму идею «виртуальной памяти».
                            0
                            Ну с тем софтом всем просто было — аналогов не было, писать свой — не вариант. На некоторых моделях машина в своп все-таки залезала, но на скорости расчетов особо не сказывалось это — перегнать пару гиг на SAS 15K не очень много времени занимает.
                            Идея виртуальной памяти — да, костыль. Но без него никуда. Он помогает в случае если нагрузки значительно превышают запланированные. Плюс помогает выгрузить из быстрой оперативной памяти те задачки, которые спят и тупо занимают оперативную память, которую можно потратить на более нужные вещи типа кеша.
                              +1
                              Опять же еще рабочий пример. Старая десктопная машина на работе. Установлено было 2 гига оперативки. Постоянно была запущена куча задач, большая часть из которых висела в фоне и открывалась пару раз за день. Почему и т.п. в данном случае не вопрос — так надо и мне так удобно. При таком количестве задач система лагала временами. Подключил своп — все летает. Подождать пару секунд пока система вытащит из свопа редко используемую задачу меня не напрягает. Держать эти задачи постоянно в памяти — смысла нет. Покупать ради них дополнительную память — тоже не имеет смысла. Повышенная нагрузка на винт? Да и фиг бы с ним, они нынче все равно обычные расходники. Да и остановка/запуск этих задач каждый раз вызовет большую нагрузку на винт, чем выдергивание их из свопа.
                                0
                                Я рад, что вы с ним подружились. На десктопе я так и не смог этого сделать, на серверах пока без него страшновато. Но все равно слежу, чтобы своп не был задействован, как только начинает заполняться на долгое время хоть на несколько процентов, по возможности добиваю памяти в сервак.
                                  +1
                                  Надо смотреть, что происходит при этом с оперативкой. Если очень хорошая ее часть отдана под кеш, то ничего страшного нет. А вот если кеш практически не занимает оперативку и у нас юзается своп, то память надо наращивать. Самое по себе использование свопа — не показатель.
                                  Пример — оперативки 16 гиг, 10 под кешем, в свопе живет гиг. Надо наращивать память? Нет. Просто какие-то процессы так долго ни фига не делали, что система решила их выкинуть в своп, и правильно сделала.
                                    –2
                                    Вы это серьёзно мне сейчас всё рассказываете?
                                      0
                                      Нет, пытаюсь на пальцах объяснить, что заполнение свопа на несколько процентов это не страшно во многих случаях. Почему на пальцах — я вас не знаю и не знаю вашего уровня подготовки.
                                        –6
                                        Не растрачивайте попусту время.
                                  • UFO just landed and posted this here
                                  0
                                  Сама идея виртуальной памяти — костыль? Напишите топик об этом, интересны ваши соображения. Мне кажется, большинство с вами не согласится.
                                    –1
                                    О чем статью? Это ж заметки Капитана получатся. Почитайте просто историю, хотя бы на вики. Своп упростил жизнь только лишь программистам, они-то может и не согласятся, что это костыль.
                                      –2
                                      Где именно почитать? На вики ничего похожего на «костыль» не увидел. И от коллег никогда такого не слышал. Поэтому такое мнение для меня неожиданно, и интересны ваши соображения на этот счет.
                                        +2
                                        History
                                        In the 1940s and 1950s, before the development of virtual memory, all larger programs had to contain logic for managing two levels of storage (primary and secondary); one such management technique is overlaying. The main reason for introducing virtual memory was therefore not simply to extend primary memory, but to make such an extension as easy as possible for programmers to use.
                                        Перевод нужен?
                                    • UFO just landed and posted this here
                                        0
                                        Вы кажется немного не туда ответили. :)
                                        Я-то с этим согласен.
                                        • UFO just landed and posted this here
                                    0
                                    Зачем тут ядру стопориться? 4й редхат себя так не ведет: возьмет ружжо и пристрелит самых невезучих. 3й редхат мог начать активно свопиться (при >4гб, например я имел проблему как раз при 8гб ), и не менее активно вытягивать из свопа данные. В результате kspawd и kscand уводили операционку состояние, когда load average выше чем когда-либо и отзывчивость системы обратно пропорционально load average.
                                      0
                                      Я не знаю почему именно оно стопорится, но на самом последнем RHEL4. При запуске этой задачи если своп+память меньше запрошенного объема, то получаем полный стоп системы с паникой и дампом. Местные программеры ковырялись, сказали что стоп идет в момент когда задача пытается отожрать память. В детали я особо не вдавался — и без этого дел хватает.
                                        0
                                        Вчера нацарапал proof of concept: paste.org.ru/?zr3t3t (сорри за быдлокод, я не программист, и уже 6 лет не писал на C)
                                        malloc выделит на 64 битном ядре без проблем выделит 255 гиговых кусочков памяти (при том что на тестируемом тазике всего 8 виртуальной).
                                        ps uaxww это подтвердит.
                                        Однако если на вопрос «may I eat allocated %d gb memory?» ответить y, то эта штука вытеснит всех в своп (если такой есть), когда тот кончится — проснется OOM и будет жутко тупить?
                                          0
                                          Ой, отправилось раньше времени:

                                          Если свопа нет — OOM проснется быстрее.
                                          при этом в top вылезет этот процесс, и значение поля VIRT будет может поразить админа…
                                          И самое главное — при этом тестируемый редхат не будет падать в kernel panic.
                                            0
                                            Спасибо за пример.
                                            В принципе я в курсе, что такое поведение программы не должно приводить к падению ядра, но в случае с тем софтом — у меня нет исходников и я не знаю как именно программа пытается память запросить и как/на каком языке она написана. То есть могу только говорить о том, что такое есть и видел/вижу такую проблему своими глазами, при том софт запускается под обычным юзером. Проблема решается увеличением свопа или наращиванием оперативки.
                                          • UFO just landed and posted this here
                                              0
                                              Гммм… Очень даже может быть.
                                        +2
                                        Мы рассматриваем своп как некую гарантию работы сервера на этапе, когда память уже кончилась, сработали оповещения мониторинга, но еще не начал стрелять oom-killer и не вмешался админ.
                                        А так вы правы, своп — это не очень хорошо, только все зависит от инсталляции и того, чем занимается сервер. Если в кластере где-либо случится splitbrain после отработки oom-killer, то пусть лучше все будет в костылях и медленно, но без этого ада.
                                          –3
                                          Аминь.
                                      0
                                      Иногда память УЖЕ НЕ ЛЕЗЕТ!!! ;)
                                      Или стоит как самолет.
                                        0
                                        Не лезет — это да. Но в любом случае, своп поможет лишь как временное решение, отмасштабировать за счет него не выйдет )
                                    0
                                    Свап используется для того, что бы после окончания памяти система могла произвести форк, а не для того, что бы доказывать что он устарел и никому не нужен. Если oom-killer не успеет почистить процессы, то сервер так и останется висеть до перезагрузки.

                                    По поводу дополнительной памяти — спорное утверждение. Есть конфигурации со 128 Гб и 256 Гб, которые используются для обработки очень большого количества данных. Воткнуть туда доп планку памяти — возможности нет. Новые планки по 32 Гб я не видел, да и не думаю что мать их будет поддерживать.
                                  +1
                                  Живу несколько лет без swap на девелоперской Slackware. Иногда (очень редко) во время компиляции make вылетает с ошибкой — не хватает памяти. К счастью, при повторном запуске make, проект (до)собирается без проблем. Иксы не использую. Собираю только свои проекты. Из сервисов запущена только Samba. Чуть не забыл — виртуальной машине, под которой работает Slackware, я отвёл 128Мб ОЗУ.

                                  Что касается разделов, то использую следующую схему — поскольку самое ценное на девелоперской машине лежит в /home, то система и /home разнесены на разные виртуальные жесткие диски. Бэкап заключается в упаковке виртуального диска, содержащего /home и переносе его на внешние носители. Бэкап самой операционной системы не делается, поскольку она в стандартной конфигурации и всегда есть возможность установить систему с установочного диска.

                                  Хочу заметить, что используемая мной конфигурация весьма специфична и имеет смысл, только если система используется исключительно для разработки и использует стандартные средства разработки, поставляемые в дистрибутиве. Единственное, что мне придётся править в случае установки системы — файлы конфигурации Самбы. Но это не проблема — дело ~5 минут.
                                    0
                                    У вас потребности видать скромнее…
                                      0
                                      ну я на домашнем десктопе установил на всякий случай своп в 2гб, но на практике при такой загрузке:

                                      — Хром с 15-20 вкладками
                                      — Еклипсина для ЕЕ-разработчиков, в которой билдю небольшие проектики (сорсы около 15мб), в памяти висит Google AppEngine Development Server, GWT Dev Console.
                                      — плеер музыку играет
                                      — скайп, емпати (или как там его — аська, гтолк)
                                      — иногда запускаю ФФ потестить что-то.

                                      может еще чего небольшое.

                                      Конфигурация — ubuntu 11.04 x64, 4GB RAM

                                      Как не посмотрю — всего своп занят на 0% (иногда правда бывало что-то вроде 0.12% но память свободна — может глюк какой).

                                      Не сказал бы что скромные потребности — вроде как обычный десектопный девело-юзер. Но толку от свопа при таком использовании действительно нет.
                                      +4
                                      Грепни messages на предмет OOM :-)
                                      0
                                      Этот ваш своп только тормозит жёсткий диск и замедляет работу компьютера. Лучше уж памяти купить.
                                      +1
                                      Для однодисковых систем достаточно такой GPT-разбивки:
                                      1 раздел: меньше мегабайта — загрузчик.
                                      2 раздел: свободное пространство около 4 ГБ под SWAP или систему быстрого восстановления.
                                      3 раздел: собственно, сама система со всеми своими каталогами, около 25-30 ГБ.
                                      4 раздел: домашние каталоги пользователей, размер — у кого как.
                                      5 раздел: архив мультимедиа высокой доступности, остальное пространство диска.

                                      Для особо въедливых с MBR-слайсом BSD-разделы такие:
                                      ad4s1a — система, 5-10 ГБ
                                      ad4s1b — SWAP, 1-4 ГБ
                                      ad4s1d — /usr/local, 8 ГБ
                                      ad4s1e — /var, 1 ГБ (зависит от предназначения системы, можно использовать на RAM-диске)
                                      ad4s1f — /tmp, 2 ГБ (можно отказаться от дискового размещения, использовать на RAM-диске)
                                      ad4s1g — /usr/home
                                      ad4s1h — /archive

                                      Каталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы, так как для них достаточно переопределить переменные окружения и не быть зажатыми в конкретных размерах разделов, да и «букв» на MBR и так мало.
                                        +7
                                        >однодисковых систем
                                        >высокой доступности
                                        что-то тут не так (:
                                          +2
                                          Всё так. Под высокой доступностью автор комментария, я полагаю, понимал то, что эта мультимедиа высоко доступна в этих наших интернетах.
                                          +1
                                          Для BSD создавая раздел /var размером 1 ГБ нужно отдавать себе отчет в том, что по умолчанию туда складываются такие вещи как:
                                          в /var/db/mysql создаются БД и бин-логи
                                          в /var/db/portsnap хранятся метаданные portsnap
                                          а так же данные freebsd-update
                                          ну и /var/log без присмотра оставлять нельзя
                                            0
                                            Про /var я же написал: в зависимости от условий использования.
                                              0
                                              Наполнение несколькими миллионами /var/spool/mqueue может исчерапть не только место, а также inode. Ошибка такая же как и от пустого места. Легко обнаруживается df -i, но куда реже на это взводится мониторинг. Вообще коварная штука.
                                            –1
                                            10 гигабайт рут?! Да вы с ума сошли!
                                              0
                                              Это в пределе, когда каталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы. А ещё есть /usr/src…
                                                0
                                                Нафига 10 гигов на рут, когда там RO и 200-300 метров по уши хватает?
                                                  0
                                                  Если носитель — флэшка. Её же не будешь разбивать на отдельные разделы.
                                                    0
                                                    Всё равно рут выводится на левый раздел, /usr, /var, /tmp можно и скопом.
                                                      0
                                                      А смысл?
                                            0
                                            если советуете использовать ext*, то тогда бы еще tune2fs -m помянули бы, все же 5% под рута это слишком много
                                              +1
                                              так в итогах же написано.
                                                0
                                                -m0 тоже не безопасно, делайте -m0.5
                                                  +2
                                                  а в чем проявляется опасность?
                                                    0
                                                    … особенно на разделах, отличных от корневого и содержащих /root и, может быть, /var
                                              +5
                                              А нет ли тут противоречия — «бьем на разделы, т.к. не хватает дискового пространства»?

                                              Я неоднократно сталкивался с ситуацией, когда некая прога радостно пишет себе лог в /var/log допустим, на разделе /var кончается место, и тут мы начинаем паниковать, нихочу-немогу-работать-места-нету-спасите-помогите. Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
                                              При этом на остальных-то разделах места навалом, бери-нехочу.
                                              А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа. Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
                                                +3
                                                > Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
                                                Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.

                                                Ну это вы зря так, считаете. Мне как-то достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута.
                                                  +1
                                                  блин, рано отправилось.
                                                  должно было быть вот так:
                                                  > Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
                                                  Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.
                                                  >А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.
                                                  Так пользователей может быть очень много (:

                                                  >Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
                                                  Ну это вы зря так, считаете. Мне как-то недавно достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута. И это у меня не единичный случай был.
                                                    0
                                                    у меня было до десяти тысяч пользователей в /home, и каждому выставлялись индивидуальные дисковые мягкие и жесткие квоты. никаких проблем с этим нет
                                                    0
                                                    После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута

                                                    от таких моментов помогает хорошо настроенный мониторинг системы
                                                    –5
                                                    Мораль: всегда, абсолютно всегда используйте LVM.
                                                      +2
                                                      не стоит использовать LVM без рейда…
                                                        0
                                                        Точно. Если диск бякнется, то с ext2/3/4 еще можно данные вытащить ручками или спец-тулзами. С LVM их вытащить нереал, если только внезапно не появились тулзы, которые это умеют делать.
                                                    +4
                                                    И все это лучше через LVM размечать.
                                                      0
                                                      Угу. И желательно поверх рейда.
                                                        +1
                                                        если используется RAID0, то LVM его успешно заменяет
                                                          +3
                                                          Ну это надо быть настоящим камикадзе, чтобы просто страйпить диски и хранить там ценные данные.
                                                            0
                                                            мне думается, истинные камикадзе используют аппаратные RAID'ы
                                                      +9
                                                      Придерживаюсь иного мнения, как ни странно: чем скромнее разбивка, тем лучше.
                                                      Выделять по каждый чих — /boot, /usr, /var, /home, /tmp — считаю нецелесообразным. В итоге со временем получается хронический перекос: на одних разделах ничего толком не занято из выделенного, но суммарное свободное пространство не получится использовать под что-то более значимое, зато другие рано или поздно переполнятся.
                                                      Наиболее целесообразным мне кажется деление дисков на разделы под общеиспользуемые и системные данные (/boot, /etc, /lib, /bin, /usr, /var за некоторыми исключенями) и пользовательские (/home, /srv, /var/lib и т.п.). А /tmp или своп всегда можно и в образе подмонтировать оперативно.
                                                      А вообще, LVM рулит, да. :)
                                                        +2
                                                        Рулит не LVM (на котором логические тома так же имеют фиксированный размер, а значит склонны к «перекосу»), а ZFS, где отдельным файловым системам доступно всё пространство пула, если они специально не квотированы.
                                                          0
                                                          Жаль, под Linux ZFS не доступна, а reiser4 практически мертва.
                                                            0
                                                            куда делась ZFS?
                                                            есть zfs-fuse, есть Native ZFS
                                                        +6
                                                        Все разделы, куда обычный пользователь имеет права на запись (/home; /tmp; /var/tmp), необходимо вынести в отдельные разделы.
                                                        С /home — возможно, остальные — не факт, что нужно:
                                                        при переустановке системы нет необходимости впопыхах переносить данные пользователей на другие носители / восстанавливать что откопалось из протухших бэкапов годовалой давности
                                                        Кто восстанавливает /tmp и /var/tmp? И кто их вообще бэкапит?
                                                        получаем возможность монтировать данные разделы с noexec, чтобы злостные кулхацкеры не запускали всякую дрянь в вашей системе.
                                                        Бесполезно и даже вредно (кроме параноидально настроенных серверов, но их администраторам не нужны такие статьи).
                                                        спасаемся от hard-link атаки

                                                        Сколько SUID-файлов подвержено уязвимостям?
                                                        можем использовать в /tmp файловую систему ext2 (журналирование здесь ни к чему, т.к. в случае сбоя восстанавливать ничего не нужно)
                                                        А можем и не использовать. Зависит от конкретного случая же.

                                                        Стоит помнить, что у нас есть замечательный /var/log, который очень любит забиваться логами под завязку
                                                        man logrotate
                                                        Все подобные разделы (/var; /home; /tmp) так же желательно вынести за пределы корня.
                                                        Ага. Вынести /var, поставить systemd, получить проблемы на ровном месте.
                                                        Весьма сомнтельная мера, однако не раз встречал подобную рекомендацию: монтировать /usr в readonly.

                                                        В последний раз, когда я монтировал /usr в readonly, он был в squashfs. Быстро смонтировал поверх него rw-ветку через aufs и получил работающее обновление.
                                                        на пользовательских разделах стоит ставить nosuid и nodev.
                                                        Нет, их нужно ставить на сменных носителях. Пользовательским разделам это побоку.
                                                          +1
                                                          Бесполезно и даже вредно
                                                          А в чем проявляется вред?
                                                          Кто восстанавливает /tmp и /var/tmp? И кто их вообще бэкапит?
                                                          Ну там же написано, что нет необходмости переносить _данные пользователей_, а не данные с /tmp, /vat/tmp и /home.
                                                          Сколько SUID-файлов подвержено уязвимостям?

                                                          man logrotate
                                                          Увы, logrotate не спасает от внезапного переполнения логов по вине форс-мажорного случая. Это работа мониторинга, однако не всегда бывает возможность моментально исправить косяк.
                                                            0
                                                            Про suid файлы забыл:
                                                            Сколько SUID-файлов подвержено уязвимостям?

                                                            Да даже в том же sudo время от времени находят уязвимости. Так что тут процесс совершено непредсказуемый.
                                                              0
                                                              А в чем проявляется вред?

                                                              Это вообще не защищает ни от чего (да, скрипты). И это ломает тонну .run-файлов, к примеру.
                                                                0
                                                                В сети полно бинарников для брутфорса паролей, попытки повышения привилегий и т.д. noexec защищает именно от них.
                                                                Насчет run файлов и различных скриптов в пакетах, то тут стоит немного перенастроить менеджер пакетов. В том же apt в настройках можно легко изменить временную директорию.
                                                                И повторюсь еще раз, все эти аспекты носят рекомендательный характер и очень сильно зависят от задач, возложенных на сервер.
                                                                  0
                                                                  В сети полно бинарников для брутфорса паролей, попытки повышения привилегий и т.д. noexec защищает именно от них.

                                                                  В практически любой системе есть тьюринг-полный скриптовой язык. От python bruteforcer.py ни один noexec не спасёт.
                                                                  Насчет run файлов и различных скриптов в пакетах, то тут стоит немного перенастроить менеджер пакетов.

                                                                  На девелоперской машине далеко не всё управляется пакетным менеджером. Как и на многих серверах. Закрытых программ полно.
                                                                  на сервер.

                                                                  А серверы слишком разные, чтобы давать хоть какие-то общие рекомендации.
                                                                    0
                                                                    В практически любой системе есть тьюринг-полный скриптовой язык. От python bruteforcer.py ни один noexec не спасёт.
                                                                    Тем не менее на одну лазейку будет меньше. Спится спокойнее.
                                                                    На девелоперской машине далеко не всё управляется пакетным менеджером. Как и на многих серверах. Закрытых программ полно.
                                                                    Для закрытых программ не из репозитория есть /opt. Для открытых программ не из репозитория есть админ, который собирает пакеты. Если админ этого не делает, то это не очень хороший админ (речь идет про бинарные дистрибутивы).
                                                                    А серверы слишком разные, чтобы давать хоть какие-то общие рекомендации.
                                                                    Общие принципы настройки любого сервера приблизительно одинаковые.
                                                                      0
                                                                      Я думаю, речь не столько о брутфорсерах, сколько о сишных эксплойтах, которые надо скомпилировать на целевой (атакуемой) машине и запустить. Во всяком случае, тех, которые так просто на питоне не переписать. :-)
                                                                  0
                                                                  >Увы, logrotate не спасает от внезапного переполнения логов по вине форс-мажорного случая
                                                                  Что мешает поставить newsyslog, добавить ограничения по размеру файлов и забыть про форс-мажор?
                                                                +3
                                                                /tmp выносить никуда не нужно. Куда лучше примонтировать в /tmp tmpfs.
                                                                  0
                                                                  Вот тут-то может и понадобится swap.
                                                                    0
                                                                    Свап системе однозначно нужен, и не только для этих целей — банально, чтобы неактивные процессы память зря не занимали.
                                                                      0
                                                                      $ df -h | grep tmpfs
                                                                      tmpfs 756M 58M 699M 8% /tmp

                                                                      ни разу больше ~200мб занято не было.
                                                                    +1
                                                                    Как же я рад, что появились новые ФС. В zfs такого дележа нет :) и настройки раздела можно менять в любое время.
                                                                      0
                                                                      И очень приятно его потом воскрешать.
                                                                        0
                                                                        Ни разу c 2006 года не воскрешал. Наверное, что-то неправильно делаю.
                                                                          0
                                                                          О том, как воскрешать лучше думать ДО того как придётся.
                                                                            +1
                                                                            ДО того, как придётся, надо думать о бэкапе, а не о наличии или отсутствии fsck…
                                                                        0
                                                                        Только производительность у zfs пока не на высоте. phoronix тесты проводил, ext4 показала несравненно лучшие характеристики.
                                                                          +2
                                                                          Что они там намеряли, мало кого волнует, из использующих ZFS. Потому что меряли они производительность не нормальной ZFS, а костыля под линуксом. Такие дела.
                                                                        0
                                                                        что-то про /tmp с nosuid и noexec ничего не увидел
                                                                          0
                                                                          что-то про /tmp с nosuid и noexec ничего не увидел
                                                                          Читайте внимательнее. Все есть (:
                                                                            0
                                                                            Ага, /tmp c noexec, а потом какой-нибудь программист плачет, что у него в mc архивы по Enter не просматриваются.
                                                                            mc выполняет скрипты для своей vfs в /tmp/mc-user
                                                                            0
                                                                            mount --bind -o noexec /tmp/ /tmp/
                                                                            Чем плох?
                                                                              +3
                                                                              Весьма странные рекомендации. Во-первых, касательно серверов, разбивку сервера всегда надо делать на 100-200Mb /boot + LVM. Если вы конечно не оригинал и не используете какую-нибудь нестандартную ФС или ещё какой-нибудь финт ушами.

                                                                              Дальше: на серверах не надо бекапить /home, а /tmp вообще никогда не надо бекапить, поэтому выносить /home, /tmp, /var/tmp на отдельные разделы элементарно глупо. Касательно всяких noexec — это вообще какая-то древнейшая байка.

                                                                              Имеет некий смысл выносить /var отдельным разделом, поскольку это чуть ли не единственное место ФС, которое таки немного склонно к полному забиванию, и не только за счёт логов, хотя и из-за них любимых тоже, поскольку в logrotate установленные не через репозитории приложения часто не прописываются и за этим можно элементарно не уследить.

                                                                              Дальше: если это какой-то корпоративный сервер, то скорее всего на него имеет смысл поставить XenServer, в котором гонять несколько виртуалок, а не тупо использовать 1% возможностей железа. Для виртуалок таки актуален swap, ибо виртуалкам памяти много выделять бессмысленно.

                                                                              Ну итого: Для Debian я использую такую схему: 100Mb /boot + LVM, LVM поделен на 1,5Gb /root + 1Gb /var (+ 1Gb swap для виртуалок), всё остальное дисковое пространство висит в VG на всякий случай.
                                                                                +1
                                                                                разбивку сервера всегда надо делать на 100-200Mb /boot + LVM.

                                                                                У меня устойчивое впечатление, что итоги никто не читает. там же написано про lvm. к тому же, lvm не спасает от создания остальных разделов. Просто в случае чего будет легче перекроить на лету. Особенно в случае с каким-нибудь jfs2.
                                                                                на серверах не надо бекапить /home

                                                                                Ну что вы привязывайтесь к точкам монтирования. Я же специально написал про отсутствие универсального решения. И специально объединил группу, как «пользовательские данные». Это вполне себе может быть и /var/www и что-то другое. Все зависит от вашего конкретного случая.
                                                                                а не тупо использовать 1% возможностей железа

                                                                                Это все зависит от задач и самого железа. Иногда железа и без виртуализации не хватает.
                                                                                  0
                                                                                  Кстати, такой вопрос: в XenServer тоже используется LVM, как это сказывается на быстродействии, если в виртуалке тоже LVM?
                                                                                  0
                                                                                  Никогда не понимал зачем на десктопе кучу разделов плодить
                                                                                  / /home и какой-нить /media плюс если надо, то swap и всё!
                                                                                    +1
                                                                                    В самом начале написано же:
                                                                                    С виду простой вопрос на самом деле таит в себе множество подводных камней. Если, конечно же, дело касается серверов. На десктопах все гораздо скучнее и серее.
                                                                                      +1
                                                                                      Сейчас объясню.
                                                                                      1). Корневой раздел, как правило, нельзя монтировать в режиме Read-Only, потому что система хочет писать в /etc/mtab, как минимум. Но защитить программные каталоги от искажения разными хакерами и от случайностей надо. Приходится выносить /usr на отдельный раздел и монтировать его с Read-only.
                                                                                      2). Несколько каталогов содержат данные, изменяемые пользователем. В них не должно попадать что-либо исполняемое, чтобы не запустить невзначай троянца. Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
                                                                                      3). /tmp вообще не нужно хранить между сеансами работы — выносим его в tmpfs.
                                                                                      4). Раздел загрузчика /boot. Он настолько редко меняется, что ему не нужна журналируемая файловая система. Да и вообще, он нужен только загрузчику; загруженная система может работать без него. Значит, выносим в отдельный раздел (который будет загрузочным) и не монтируем вообще. Не забываем только подмонтировать в моменты обновления системы, когда будет обновляться ядро.
                                                                                      5). Медиа-раздел: кинофильмы, музыка и всё такое крупное. Крупные вещи хорошо работают на системе XFS. Значит, выносим на отдельный раздел, со своей файловой системой.

                                                                                      Итак, если мы хотим добиться максимальной защищенности и производительности, нам потребуются отдельные разделы:

                                                                                      /
                                                                                      /boot
                                                                                      /usr
                                                                                      /home
                                                                                      /var
                                                                                      /srv (если там что-то держим)
                                                                                      /tmp
                                                                                      /mnt/multimedia
                                                                                      /opt (спорно и не всегда требуется)

                                                                                      (не забудьте еще про swap, если нужен — правда, вы о нем уже упомянули)
                                                                                        0
                                                                                        ЗЫ. Забыл добавить, что здесь речь я веду о десктопе, и свою домашнюю систему настроил именно так. На серверах, возможно, будет всё попроще, потому что там не происходит собственно пользовательская работа, нет мультимедиа-помойки; jgthfwbjyrb могут быть разделены системами виртуализации.
                                                                                          +1
                                                                                          >Но защитить программные каталоги от искажения разными хакерами и от случайностей надо. Приходится выносить /usr на отдельный раздел и монтировать его с Read-only.
                                                                                          Если хакер получил права, достаточные для записи в /usr, то ему хватит прав и перемонтировать его в rw. Это защита только от скриптинг-кидзов.

                                                                                          >Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
                                                                                          Угу. В /var могут находиться chroot для некоторых сервисов с копиями нужных для работы бинарников. Их тоже в отдельные от /var разделы выносить, чтобы они могли работать?
                                                                                          В /home в нормальных многопользовательских системах, например HPC, юзеры ходят по ssh в свои домашки и хотят запускать свой скомпиленный софт.

                                                                                          >swap, если нужен
                                                                                          Свап нужен всегда. Хотя бы на гиг-два. Спящие процессы предлагаете постоянно в памяти держать? Пусть лучше они в своп выгрузятся и отдадут свободную оперативку под файловый кеш.

                                                                                          Опять же, как уже писали неоднократно тут, — noexec это ни фига не защита. /bin/sh /tmp/backdoor.sh и по фигу ему на ваш флаг, или на stdin содержимое скрипта передать интерпретатору. Сейчас даже скрипт-кидзы запускают бюкдоры таким образом.
                                                                                        0
                                                                                        По опыту могу сказать, что при переполнении /var/log многие сервисы перестают работать.
                                                                                          0
                                                                                          почти все. Но за логами надо следить отдельно и правильно настраивать само логирование, тогда никаких переполнений не будет.
                                                                                            0
                                                                                            А что Вы будете делать, если у Вас резко возрастет трафик и логи какого-нить nginx`а начнут занимать по 2-3 гига за день?
                                                                                            P.S. Усложняем задачу, по правилам работы все логи за все время существования сервера должны сохранятся и делать это на данном сервере ;)
                                                                                              0
                                                                                              Согласен, только всегда нужно оценивать целесообразность. Если настолько критично — можно для логов отдельную СХД поднять.
                                                                                                0
                                                                                                Вам, очевидно, всегда везет с заказчиками :)
                                                                                                А у меня вот на одном проекте заказчик просто как-то ночью спросил вытянем ли мы 8 миллионов хитов в день, я ответил что должны и утром я получил этот трафик, то есть тупо нельзя было на ходу увеличить место под логи, справились конечно, даже не было особых проблем, но было очень неприятно видеть, как место улетает.
                                                                                          +1
                                                                                          Фотка понравилась.
                                                                                            +1
                                                                                            > Старайтесь выносить из корня в отдельные разделы /boot, /home, /tmp, /var.

                                                                                            Зачем выносить в отдельные разделы /var и /tmp?

                                                                                            Что за бредовый совет?
                                                                                              –1
                                                                                              /var — для защиты от нехватки места на рутовом разделе.
                                                                                              /tmp — для возможности использования нежурналируемой фс и своих опций монтирования.
                                                                                              Я же обосновал каждый отдельный раздел в статье.
                                                                                                +2
                                                                                                И что же такого страшного произойдет при нехватке места на рутовом разделе? В обоих случаях большинство служб отвалится все равно. ssh для решения проблемы можно будет использовать в обоих случаях.
                                                                                                /tmp вообще лучше через tmpfs или через файл монтировать.
                                                                                                На вкус и цвет все фломастеры разные. Каждый админ разбивает так как привык. Нет рекомендаций, которые бы всем подошли.
                                                                                                  –2
                                                                                                  Если кончится место в /var/log, по ssh не присоединиться, т.к. нет места на диске залогировать это действие.
                                                                                                    0
                                                                                                    На практике проверяли? Я неоднократно заходил по ssh на сервера, где закончилось свободное место и половина сервисов отваливалась. Допускаю, что при этом использовались 5%, зарезервированные в файловой системе под рута, т.к. ssh с правами рута работает и логи пишет.
                                                                                                      +2
                                                                                                      Вы совершенно правы, в таких случаях юзается место зарезервированное под рута, именно поэтому его совсем в 0 уводить нельзя.

                                                                                                      P.S. Это и мой ответ на вопрос выше, часто отвечать не могу.
                                                                                                        0
                                                                                                        Уводить в 0 можно и даже нужно, но с умом. Зачем мне на файловом хранилище размером в 10Tb, замонтированном в /home, терять/держать 500 гиг в резерве под рута, когда он туда ни одного файла вообще не пишет?
                                                                                                        Встречал варианты разбивки, когда большое хранилище не били, а использовали как есть. Опять же — смысл на 10Тб (объем тупо для примера) держать в резерве 500 гиг? Если файловую систему переполнили сервисы, пишущие под рутом, то что 500 гиг, что террабайт — не спасут. Достаточно оставить 0.1% или даже меньше, чтобы рут мог зайти и поправить ситуацию.
                                                                                                        Итого: В ноль уводить надо там, где это действительно нужно, а на корневой ФС или /var — по ситуации можно уменьшить значение по умолчанию.
                                                                                                          +1
                                                                                                          Да я сам постоянно напоминаю всем, что 5% это зверски много, на вот если у Вас /var или даже /var/log отделен, на нем нужно оставлять хотя бы 0.5%, это спасет при переполнении
                                                                                                          А в случае с /home можно и в 0, Вы совершенно правы.
                                                                                                          Главная же беда в том, что очень многие просто не знают или забывают про эти 5%(а больше всего меня удивляет, что в /etc/mke2fs.conf не выставляют значения ниже в основных дистрибах)
                                                                                                        0
                                                                                                        При заполнении корневого раздела действительно ничего страшного не должно произойти.
                                                                                                        /var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.

                                                                                                        Буквально на днях видел сервер у которого даже /sbin/shutdown был сломан из-за повреждения структуры файловой системы. Как раз всё было на одном разделе на RAID1.
                                                                                                          0
                                                                                                          >/var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.
                                                                                                          А смысл, если устройство все равно одно? Вот если на отдельный диск/массив, то да — однозначно лучше. В случае одного устройства получаем в комплекте с дополнительной ФС еще один набор мета-данных, которые надо читать и кешировать отдельно от основной ФС. Так что спорный вопрос. Интересно, есть где-нибудь реальные замеры — как эффективнее в плане скорости?

                                                                                                          Раид раиду рознь. Встречал массив 0+1 на дешевом контроллере, где при вылете одного диска рассыпался весь массив. Я считаю, что надо юзать либо нормальные аппаратные контроллеры, а если на них нет денег, то нативный софтовый раид линукса.
                                                                                                            0
                                                                                                            Если файловая система замонтирована RO или в нее никто не пишет, то вероятность ее логической поломки существенно снижается. Повторюсь — у меня буквально на прошлой неделе был сервер, у которого (софт)RAID1 целый, но файловая система (метаинформация) развалена. Ни RAID ни журнал ФС не спасли. Какова причина этого сбоя сказать трудно, но я уверен, что если бы /sbin не пострадал, то сервер наверняка прочекал бы /var и все работало бы дальше.
                                                                                                              0
                                                                                                              Честно говоря за 13 лет ни разу такого не было. Если система стоит не на массиве, то при деградации диска без разницы как смонтирована ФС. На системах с аппаратными raid-контроллерами или нативным софт-raid линуксов тоже такое не видел. А вот в полусофтовых контроллерах каких только барабашек не встречал.
                                                                                                              Софт раид был родной линуксовый?
                                                                                                              И как интересно вы спасете /sbin? Корневую ФС в RO монтировать — не проканает. /sbin вынести на отдельный раздел — тоже.
                                                                                                  0
                                                                                                  Совет вовсе не бредовый. Обычно разносят те файловые системы, модели доступа к данным которых сильно отличаются из-за требований (скорость, надежность, отказоустойчивость, персистентность данных между ребутами, шифрование и/или integrity verification, et cetera). Различные требования в свою очередь диктуют, какие именно файловые системы и опции монтирования лучше подходят в каждом случае.
                                                                                                  0
                                                                                                  Я всегда размечаю /, swap, /boot и /home. Остальное для десктопа излишне.

                                                                                                  LVM не использую, т.к. не приходится часто переразметку делать и не нашёл информации по тому, какой у него оверхед.
                                                                                                    0
                                                                                                    Оверхед LVM: сотни килобайт или считанные мегабайты. Мало зависит от объема разделов.

                                                                                                    Для примера в моей машинке 250гиговый винт, на нем один primary раздел, выделенный под одну группу:
                                                                                                    fdisk -lu | grep sdb1
                                                                                                    /dev/sdb1 63 488392064 244196001 8e Linux LVM

                                                                                                    т.е. выделено 244196001*1024 — 250056705024 байт раздела.

                                                                                                    LVM — на уровне physical volume оперирует physical extent-ами (PE)
                                                                                                    vgdisplay vol3 | grep PE
                                                                                                    PE Size 4.00 MiB
                                                                                                    Total PE 59618
                                                                                                    ..

                                                                                                    т.е. доступно 59618 * 4*1024*1024= 250056015872 байт под Logical Volumes.
                                                                                                    250056705024-250056015872 = 689152 = 673 кб.
                                                                                                      0
                                                                                                      Я производительность имел ввиду. Объём при нынешней цене мегабайта сейчас мало кого интересует.
                                                                                                    0
                                                                                                    Пратически на всех linux web и db серверах разбиваю только 2 раздела "/" и swap.
                                                                                                    LVM — плюс одна точка отказа.
                                                                                                    Только раз за много лет пришлось заюзать swap под noexec, а сам swap — файлом на fs.
                                                                                                      0
                                                                                                      всегда разбиваю на /boot, / и /home
                                                                                                      /boot — ext2, чтобы ядро быстрее грузилось, незачем грабу лезть в ext4/btrfs, да и изменяется на нем что-либо редко.
                                                                                                      особого смысла выделять /tmp не вижу, проблема с noexec решается элементарно mount -o bind /tmp /tmp, mount -o remount,noexec /tmp. Разве что делать его на tmpfs.
                                                                                                        +2
                                                                                                        > Особой нужды в свопе на системах нынче нет.
                                                                                                        Швоп — это ваша подушка безопасности.
                                                                                                        Когда по какой-то причине память кончается, без швопа мы сразу теряем процессы убитыми (и не факт, что именно те, что породили проблему, зачастую OOMkiller убивает самый жирный процесс, например базу данных, после чего серверу становится сразу еще хуже — клиенты пытаются подлкючиться а без б.д. их запросы не обрабатываются.сюда же можно отнести время на восстановление скажем побившейся от такого базы данных, которое будет не моментальным). В случае швопа вы получаете очень заметные тормоза еще до того, как память кончится совсем, и у вас есть время 1) получить сигнал от мониторинга 2) корректно на него среагировать.
                                                                                                        в общем для серверов швоп обязателен, хотя бы в минимальном объеме пары-тройки гигов.
                                                                                                          0
                                                                                                          Касательно свопа могу привести жизненный пример, высоконагруженная система, Solaris, процессоры SPARC64 VI всего 64-ядра, 130 Гб оперативной памяти и swap 16 Гб, казалось бы, куда уж больше, но в один момент при запланированном увеличении нагрузки на сервер Oracle начал выбрасывать ошибки с комментом out of memory и база начинала валиться. Пока я не создал дополнительный раздел Swap размером еще 16 Гб, oracle не успокоился. Так что для настоящих серверов 2-3 Гб маловато будет
                                                                                                            0
                                                                                                            Ну так в вашем случае вопрос не в нужности швопа, а в 1) глючности оракла (он у меня и на интелах бывало так взбрыкивал) 2) отстуствии оперативно принятых мер при начале швоппинга.
                                                                                                              0
                                                                                                              Нет, вопрос был не в глючности форума, а не правильном нагрузочном тестировании, билинговый софт работал нормально, просто в Solaris, когда занято определенное количество оперативы, а система уверена, что свопа меньше чем надо, она начинает блокировать реальную оперативную память.
                                                                                                          0
                                                                                                          Незабываем про fstab и, что лучше внести некоторые изменения для предотвращения нехороших действий.
                                                                                                          Укажем где и что можно и нельзя делать системе (FreeBSD).

                                                                                                          /dev/ad4s3b none swap sw 0 0
                                                                                                          /dev/ad4s3a / ufs rw 1 1
                                                                                                          /dev/ad4s3e /tmp ufs rw,noexec 2 2
                                                                                                          /dev/ad4s3f /usr ufs rw 2 2
                                                                                                          /dev/ad4s3f /usr/home ufs rw,nosuid,nodev 2 2
                                                                                                          /dev/ad4s3d /var ufs rw,nodev 2 2


                                                                                                          noexec – эта опция дает понять, что на данном разделе запрещено запускать что либо даже если права на файл chmod 777 (Я знаю что некоторые защищенные сервера ломали именно через /tmp :) в последствии админы советовали прикрывать эту дыру. И незабываем, что в /tmp может писать почти любой сервис в системе.

                                                                                                          nosuid – при этом значении система игнорирует suid-биты. Юзер не сможет сделать
                                                                                                          # su и подняться до рута, даже если он знает его пароль рута и находится в группе
                                                                                                          wheel

                                                                                                          nodev – запрещаем создание\существование в данном разделе специальных устройств.
                                                                                                            0
                                                                                                            Было время когда своп выносился на отдельный диск.
                                                                                                            И кстати /tmp я часто размещают в памяти для ускорения работы.
                                                                                                            TMPFS — использование RAM в качестве tmp, что само собой разумеется, быстрей и эффективней чем, он бы располагался на HDD. TMPFS появился только в FreeBSD 7.0-RELEASE
                                                                                                              0
                                                                                                              собой нужды в свопе на системах нынче нет.

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

                                                                                                              Only users with full accounts can post comments. Log in, please.