Comments 141
Сейчас решил поднять свой сервер, как раз думал
как разбить диски, и вы как чувствовали что мне надо))
Автору огромное спасибо!
как разбить диски, и вы как чувствовали что мне надо))
Автору огромное спасибо!
Свопа в два гига всю жизнь хватало…
Свопа в 0 байт хватает последние года четыре.
Сейчас компилирую C++ gSOAP-связки для самописного клиента VMware ESXi (исходник 60 Mb): все 4 Gb RAM забиты до отказа, swap на 8 Gb забит на половину…
Это всего лишь повод потратить 1000р на дополнительную память. Но не повод хрустеть диском.
не всегда. Все зависит от условий. Вот top на моем сервере:
Mem: 98868808k total, 96339528k used, 2529280k free, 176096k buffers
Swap: 52428792k total, 311080k used, 52117712k free, 41614092k cached
если бы не было свопа, то он бы падал по 5 раз в сутки.
Mem: 98868808k total, 96339528k used, 2529280k free, 176096k buffers
Swap: 52428792k total, 311080k used, 52117712k free, 41614092k cached
если бы не было свопа, то он бы падал по 5 раз в сутки.
А со свопом оно зависает 5 раз в сутки. Согласен, хорошая альтернатива. Но это не отменяет добавление памяти.
Диск добавить иногда ощутимо дешевле, чем память. У нас есть машины, где все банки под память уже заняты, а одна плашка в два раза больше, чем была, стоит больше, чем весь рабочий рейд из 10 винтов. А их парой менять.
Выделить 16 гигов под своп из терабайта для успокоения oom-killer, этого никто не заметит даже.
Если все становится плохо, инсталлируем новую железяку, что не быстро и требует разного рода длительных согласований. Со свопом 0 байт могут быть ощутимые проблемы.
Выделить 16 гигов под своп из терабайта для успокоения oom-killer, этого никто не заметит даже.
Если все становится плохо, инсталлируем новую железяку, что не быстро и требует разного рода длительных согласований. Со свопом 0 байт могут быть ощутимые проблемы.
Если места под память нет — другое дело. Но своп идеологически — костыль, это очевидно.
Когда как. Иногда не костыль, а то без чего не получается работать. Встречались нам расчетные задачки, которые при запуске пытаются у системы отожрать 16 гиг, а реально стоит только 8. При том, в работе задача реально не использует больше половины запрошенной памяти. RHEL4 при таком поведении софта тупо склеивает ласты в kernel panic. Покупать память ради того, чтобы задача могла нормально запросить нужный объем и потом его реально в расчете не использовать, немного неразумно, особенно с учетом цены плашек для серверов. В данном случае не уверен, что это костыль :)
Это костыль в третьем поколении ) Точнее тупые программисты, но это отдельная тема. Я про саму идею «виртуальной памяти».
Ну с тем софтом всем просто было — аналогов не было, писать свой — не вариант. На некоторых моделях машина в своп все-таки залезала, но на скорости расчетов особо не сказывалось это — перегнать пару гиг на SAS 15K не очень много времени занимает.
Идея виртуальной памяти — да, костыль. Но без него никуда. Он помогает в случае если нагрузки значительно превышают запланированные. Плюс помогает выгрузить из быстрой оперативной памяти те задачки, которые спят и тупо занимают оперативную память, которую можно потратить на более нужные вещи типа кеша.
Идея виртуальной памяти — да, костыль. Но без него никуда. Он помогает в случае если нагрузки значительно превышают запланированные. Плюс помогает выгрузить из быстрой оперативной памяти те задачки, которые спят и тупо занимают оперативную память, которую можно потратить на более нужные вещи типа кеша.
Опять же еще рабочий пример. Старая десктопная машина на работе. Установлено было 2 гига оперативки. Постоянно была запущена куча задач, большая часть из которых висела в фоне и открывалась пару раз за день. Почему и т.п. в данном случае не вопрос — так надо и мне так удобно. При таком количестве задач система лагала временами. Подключил своп — все летает. Подождать пару секунд пока система вытащит из свопа редко используемую задачу меня не напрягает. Держать эти задачи постоянно в памяти — смысла нет. Покупать ради них дополнительную память — тоже не имеет смысла. Повышенная нагрузка на винт? Да и фиг бы с ним, они нынче все равно обычные расходники. Да и остановка/запуск этих задач каждый раз вызовет большую нагрузку на винт, чем выдергивание их из свопа.
Я рад, что вы с ним подружились. На десктопе я так и не смог этого сделать, на серверах пока без него страшновато. Но все равно слежу, чтобы своп не был задействован, как только начинает заполняться на долгое время хоть на несколько процентов, по возможности добиваю памяти в сервак.
Надо смотреть, что происходит при этом с оперативкой. Если очень хорошая ее часть отдана под кеш, то ничего страшного нет. А вот если кеш практически не занимает оперативку и у нас юзается своп, то память надо наращивать. Самое по себе использование свопа — не показатель.
Пример — оперативки 16 гиг, 10 под кешем, в свопе живет гиг. Надо наращивать память? Нет. Просто какие-то процессы так долго ни фига не делали, что система решила их выкинуть в своп, и правильно сделала.
Пример — оперативки 16 гиг, 10 под кешем, в свопе живет гиг. Надо наращивать память? Нет. Просто какие-то процессы так долго ни фига не делали, что система решила их выкинуть в своп, и правильно сделала.
UFO just landed and posted this here
Сама идея виртуальной памяти — костыль? Напишите топик об этом, интересны ваши соображения. Мне кажется, большинство с вами не согласится.
О чем статью? Это ж заметки Капитана получатся. Почитайте просто историю, хотя бы на вики. Своп упростил жизнь только лишь программистам, они-то может и не согласятся, что это костыль.
Где именно почитать? На вики ничего похожего на «костыль» не увидел. И от коллег никогда такого не слышал. Поэтому такое мнение для меня неожиданно, и интересны ваши соображения на этот счет.
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
UFO just landed and posted this here
Я не знаю почему именно оно стопорится, но на самом последнем RHEL4. При запуске этой задачи если своп+память меньше запрошенного объема, то получаем полный стоп системы с паникой и дампом. Местные программеры ковырялись, сказали что стоп идет в момент когда задача пытается отожрать память. В детали я особо не вдавался — и без этого дел хватает.
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо за пример.
В принципе я в курсе, что такое поведение программы не должно приводить к падению ядра, но в случае с тем софтом — у меня нет исходников и я не знаю как именно программа пытается память запросить и как/на каком языке она написана. То есть могу только говорить о том, что такое есть и видел/вижу такую проблему своими глазами, при том софт запускается под обычным юзером. Проблема решается увеличением свопа или наращиванием оперативки.
В принципе я в курсе, что такое поведение программы не должно приводить к падению ядра, но в случае с тем софтом — у меня нет исходников и я не знаю как именно программа пытается память запросить и как/на каком языке она написана. То есть могу только говорить о том, что такое есть и видел/вижу такую проблему своими глазами, при том софт запускается под обычным юзером. Проблема решается увеличением свопа или наращиванием оперативки.
UFO just landed and posted this here
Мы рассматриваем своп как некую гарантию работы сервера на этапе, когда память уже кончилась, сработали оповещения мониторинга, но еще не начал стрелять oom-killer и не вмешался админ.
А так вы правы, своп — это не очень хорошо, только все зависит от инсталляции и того, чем занимается сервер. Если в кластере где-либо случится splitbrain после отработки oom-killer, то пусть лучше все будет в костылях и медленно, но без этого ада.
А так вы правы, своп — это не очень хорошо, только все зависит от инсталляции и того, чем занимается сервер. Если в кластере где-либо случится splitbrain после отработки oom-killer, то пусть лучше все будет в костылях и медленно, но без этого ада.
Иногда память УЖЕ НЕ ЛЕЗЕТ!!! ;)
Или стоит как самолет.
Или стоит как самолет.
Свап используется для того, что бы после окончания памяти система могла произвести форк, а не для того, что бы доказывать что он устарел и никому не нужен. Если oom-killer не успеет почистить процессы, то сервер так и останется висеть до перезагрузки.
По поводу дополнительной памяти — спорное утверждение. Есть конфигурации со 128 Гб и 256 Гб, которые используются для обработки очень большого количества данных. Воткнуть туда доп планку памяти — возможности нет. Новые планки по 32 Гб я не видел, да и не думаю что мать их будет поддерживать.
По поводу дополнительной памяти — спорное утверждение. Есть конфигурации со 128 Гб и 256 Гб, которые используются для обработки очень большого количества данных. Воткнуть туда доп планку памяти — возможности нет. Новые планки по 32 Гб я не видел, да и не думаю что мать их будет поддерживать.
Живу несколько лет без swap на девелоперской Slackware. Иногда (очень редко) во время компиляции make вылетает с ошибкой — не хватает памяти. К счастью, при повторном запуске make, проект (до)собирается без проблем. Иксы не использую. Собираю только свои проекты. Из сервисов запущена только Samba. Чуть не забыл — виртуальной машине, под которой работает Slackware, я отвёл 128Мб ОЗУ.
Что касается разделов, то использую следующую схему — поскольку самое ценное на девелоперской машине лежит в /home, то система и /home разнесены на разные виртуальные жесткие диски. Бэкап заключается в упаковке виртуального диска, содержащего /home и переносе его на внешние носители. Бэкап самой операционной системы не делается, поскольку она в стандартной конфигурации и всегда есть возможность установить систему с установочного диска.
Хочу заметить, что используемая мной конфигурация весьма специфична и имеет смысл, только если система используется исключительно для разработки и использует стандартные средства разработки, поставляемые в дистрибутиве. Единственное, что мне придётся править в случае установки системы — файлы конфигурации Самбы. Но это не проблема — дело ~5 минут.
Что касается разделов, то использую следующую схему — поскольку самое ценное на девелоперской машине лежит в /home, то система и /home разнесены на разные виртуальные жесткие диски. Бэкап заключается в упаковке виртуального диска, содержащего /home и переносе его на внешние носители. Бэкап самой операционной системы не делается, поскольку она в стандартной конфигурации и всегда есть возможность установить систему с установочного диска.
Хочу заметить, что используемая мной конфигурация весьма специфична и имеет смысл, только если система используется исключительно для разработки и использует стандартные средства разработки, поставляемые в дистрибутиве. Единственное, что мне придётся править в случае установки системы — файлы конфигурации Самбы. Но это не проблема — дело ~5 минут.
У вас потребности видать скромнее…
ну я на домашнем десктопе установил на всякий случай своп в 2гб, но на практике при такой загрузке:
— Хром с 15-20 вкладками
— Еклипсина для ЕЕ-разработчиков, в которой билдю небольшие проектики (сорсы около 15мб), в памяти висит Google AppEngine Development Server, GWT Dev Console.
— плеер музыку играет
— скайп, емпати (или как там его — аська, гтолк)
— иногда запускаю ФФ потестить что-то.
может еще чего небольшое.
Конфигурация — ubuntu 11.04 x64, 4GB RAM
Как не посмотрю — всего своп занят на 0% (иногда правда бывало что-то вроде 0.12% но память свободна — может глюк какой).
Не сказал бы что скромные потребности — вроде как обычный десектопный девело-юзер. Но толку от свопа при таком использовании действительно нет.
— Хром с 15-20 вкладками
— Еклипсина для ЕЕ-разработчиков, в которой билдю небольшие проектики (сорсы около 15мб), в памяти висит Google AppEngine Development Server, GWT Dev Console.
— плеер музыку играет
— скайп, емпати (или как там его — аська, гтолк)
— иногда запускаю ФФ потестить что-то.
может еще чего небольшое.
Конфигурация — ubuntu 11.04 x64, 4GB RAM
Как не посмотрю — всего своп занят на 0% (иногда правда бывало что-то вроде 0.12% но память свободна — может глюк какой).
Не сказал бы что скромные потребности — вроде как обычный десектопный девело-юзер. Но толку от свопа при таком использовании действительно нет.
UFO just landed and posted this here
Этот ваш своп только тормозит жёсткий диск и замедляет работу компьютера. Лучше уж памяти купить.
Для однодисковых систем достаточно такой 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 и так мало.
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 и так мало.
>однодисковых систем
>высокой доступности
что-то тут не так (:
>высокой доступности
что-то тут не так (:
Для BSD создавая раздел /var размером 1 ГБ нужно отдавать себе отчет в том, что по умолчанию туда складываются такие вещи как:
в /var/db/mysql создаются БД и бин-логи
в /var/db/portsnap хранятся метаданные portsnap
а так же данные freebsd-update
ну и /var/log без присмотра оставлять нельзя
в /var/db/mysql создаются БД и бин-логи
в /var/db/portsnap хранятся метаданные portsnap
а так же данные freebsd-update
ну и /var/log без присмотра оставлять нельзя
10 гигабайт рут?! Да вы с ума сошли!
если советуете использовать ext*, то тогда бы еще tune2fs -m помянули бы, все же 5% под рута это слишком много
А нет ли тут противоречия — «бьем на разделы, т.к. не хватает дискового пространства»?
Я неоднократно сталкивался с ситуацией, когда некая прога радостно пишет себе лог в /var/log допустим, на разделе /var кончается место, и тут мы начинаем паниковать, нихочу-немогу-работать-места-нету-спасите-помогите. Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
При этом на остальных-то разделах места навалом, бери-нехочу.
А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа. Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
Я неоднократно сталкивался с ситуацией, когда некая прога радостно пишет себе лог в /var/log допустим, на разделе /var кончается место, и тут мы начинаем паниковать, нихочу-немогу-работать-места-нету-спасите-помогите. Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
При этом на остальных-то разделах места навалом, бери-нехочу.
А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа. Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
> Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.
Ну это вы зря так, считаете. Мне как-то достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута.
Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.
Ну это вы зря так, считаете. Мне как-то достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута.
блин, рано отправилось.
должно было быть вот так:
> Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.
>А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.
Так пользователей может быть очень много (:
>Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
Ну это вы зря так, считаете. Мне как-то недавно достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута. И это у меня не единичный случай был.
должно было быть вот так:
> Все, сервер нерабочий, сыпет ошибки, пока не починит одмин.
Сам сервер все же остается более менее рабочим. Нерабочим становится приложение, которому не дают логи писать.
>А с нехваткой места юзерам — ну пропишите им квоты на /home, вот и не забьют до отказа.
Так пользователей может быть очень много (:
>Вообще, место на дисках по-моему кончается в последнюю очередь из того, что может кончиться.
Ну это вы зря так, считаете. Мне как-то недавно достался в наследство веб-сервер с одним единственным разделом на все-провсе. После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута. И это у меня не единичный случай был.
После обновления одного из скриптов пошел жесткий лог ошибок, увеличивался он со скоростью гигабайт/минута
от таких моментов помогает хорошо настроенный мониторинг системы
Мораль: всегда, абсолютно всегда используйте LVM.
И все это лучше через LVM размечать.
Придерживаюсь иного мнения, как ни странно: чем скромнее разбивка, тем лучше.
Выделять по каждый чих — /boot, /usr, /var, /home, /tmp — считаю нецелесообразным. В итоге со временем получается хронический перекос: на одних разделах ничего толком не занято из выделенного, но суммарное свободное пространство не получится использовать под что-то более значимое, зато другие рано или поздно переполнятся.
Наиболее целесообразным мне кажется деление дисков на разделы под общеиспользуемые и системные данные (/boot, /etc, /lib, /bin, /usr, /var за некоторыми исключенями) и пользовательские (/home, /srv, /var/lib и т.п.). А /tmp или своп всегда можно и в образе подмонтировать оперативно.
А вообще, LVM рулит, да. :)
Выделять по каждый чих — /boot, /usr, /var, /home, /tmp — считаю нецелесообразным. В итоге со временем получается хронический перекос: на одних разделах ничего толком не занято из выделенного, но суммарное свободное пространство не получится использовать под что-то более значимое, зато другие рано или поздно переполнятся.
Наиболее целесообразным мне кажется деление дисков на разделы под общеиспользуемые и системные данные (/boot, /etc, /lib, /bin, /usr, /var за некоторыми исключенями) и пользовательские (/home, /srv, /var/lib и т.п.). А /tmp или своп всегда можно и в образе подмонтировать оперативно.
А вообще, LVM рулит, да. :)
Все разделы, куда обычный пользователь имеет права на запись (/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.Нет, их нужно ставить на сменных носителях. Пользовательским разделам это побоку.
Бесполезно и даже вредноА в чем проявляется вред?
Кто восстанавливает /tmp и /var/tmp? И кто их вообще бэкапит?Ну там же написано, что нет необходмости переносить _данные пользователей_, а не данные с /tmp, /vat/tmp и /home.
Сколько SUID-файлов подвержено уязвимостям?
man logrotateУвы, logrotate не спасает от внезапного переполнения логов по вине форс-мажорного случая. Это работа мониторинга, однако не всегда бывает возможность моментально исправить косяк.
Про suid файлы забыл:
Да даже в том же sudo время от времени находят уязвимости. Так что тут процесс совершено непредсказуемый.
Сколько SUID-файлов подвержено уязвимостям?
Да даже в том же sudo время от времени находят уязвимости. Так что тут процесс совершено непредсказуемый.
А в чем проявляется вред?
Это вообще не защищает ни от чего (да, скрипты). И это ломает тонну .run-файлов, к примеру.
В сети полно бинарников для брутфорса паролей, попытки повышения привилегий и т.д. noexec защищает именно от них.
Насчет run файлов и различных скриптов в пакетах, то тут стоит немного перенастроить менеджер пакетов. В том же apt в настройках можно легко изменить временную директорию.
И повторюсь еще раз, все эти аспекты носят рекомендательный характер и очень сильно зависят от задач, возложенных на сервер.
Насчет run файлов и различных скриптов в пакетах, то тут стоит немного перенастроить менеджер пакетов. В том же apt в настройках можно легко изменить временную директорию.
И повторюсь еще раз, все эти аспекты носят рекомендательный характер и очень сильно зависят от задач, возложенных на сервер.
В сети полно бинарников для брутфорса паролей, попытки повышения привилегий и т.д. noexec защищает именно от них.
В практически любой системе есть тьюринг-полный скриптовой язык. От python bruteforcer.py ни один noexec не спасёт.
Насчет run файлов и различных скриптов в пакетах, то тут стоит немного перенастроить менеджер пакетов.
На девелоперской машине далеко не всё управляется пакетным менеджером. Как и на многих серверах. Закрытых программ полно.
на сервер.
А серверы слишком разные, чтобы давать хоть какие-то общие рекомендации.
В практически любой системе есть тьюринг-полный скриптовой язык. От python bruteforcer.py ни один noexec не спасёт.Тем не менее на одну лазейку будет меньше. Спится спокойнее.
На девелоперской машине далеко не всё управляется пакетным менеджером. Как и на многих серверах. Закрытых программ полно.Для закрытых программ не из репозитория есть /opt. Для открытых программ не из репозитория есть админ, который собирает пакеты. Если админ этого не делает, то это не очень хороший админ (речь идет про бинарные дистрибутивы).
А серверы слишком разные, чтобы давать хоть какие-то общие рекомендации.Общие принципы настройки любого сервера приблизительно одинаковые.
Я думаю, речь не столько о брутфорсерах, сколько о сишных эксплойтах, которые надо скомпилировать на целевой (атакуемой) машине и запустить. Во всяком случае, тех, которые так просто на питоне не переписать. :-)
>Увы, logrotate не спасает от внезапного переполнения логов по вине форс-мажорного случая
Что мешает поставить newsyslog, добавить ограничения по размеру файлов и забыть про форс-мажор?
Что мешает поставить newsyslog, добавить ограничения по размеру файлов и забыть про форс-мажор?
/tmp выносить никуда не нужно. Куда лучше примонтировать в /tmp tmpfs.
Как же я рад, что появились новые ФС. В zfs такого дележа нет :) и настройки раздела можно менять в любое время.
И очень приятно его потом воскрешать.
Только производительность у zfs пока не на высоте. phoronix тесты проводил, ext4 показала несравненно лучшие характеристики.
что-то про /tmp с nosuid и noexec ничего не увидел
mount --bind -o noexec /tmp/ /tmp/Чем плох?
Весьма странные рекомендации. Во-первых, касательно серверов, разбивку сервера всегда надо делать на 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 на всякий случай.
Дальше: на серверах не надо бекапить /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 на всякий случай.
разбивку сервера всегда надо делать на 100-200Mb /boot + LVM.
У меня устойчивое впечатление, что итоги никто не читает. там же написано про lvm. к тому же, lvm не спасает от создания остальных разделов. Просто в случае чего будет легче перекроить на лету. Особенно в случае с каким-нибудь jfs2.
на серверах не надо бекапить /home
Ну что вы привязывайтесь к точкам монтирования. Я же специально написал про отсутствие универсального решения. И специально объединил группу, как «пользовательские данные». Это вполне себе может быть и /var/www и что-то другое. Все зависит от вашего конкретного случая.
а не тупо использовать 1% возможностей железа
Это все зависит от задач и самого железа. Иногда железа и без виртуализации не хватает.
Кстати, такой вопрос: в XenServer тоже используется LVM, как это сказывается на быстродействии, если в виртуалке тоже LVM?
Никогда не понимал зачем на десктопе кучу разделов плодить
/ /home и какой-нить /media плюс если надо, то swap и всё!
/ /home и какой-нить /media плюс если надо, то swap и всё!
В самом начале написано же:
С виду простой вопрос на самом деле таит в себе множество подводных камней. Если, конечно же, дело касается серверов. На десктопах все гораздо скучнее и серее.
Сейчас объясню.
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, если нужен — правда, вы о нем уже упомянули)
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, если нужен — правда, вы о нем уже упомянули)
ЗЫ. Забыл добавить, что здесь речь я веду о десктопе, и свою домашнюю систему настроил именно так. На серверах, возможно, будет всё попроще, потому что там не происходит собственно пользовательская работа, нет мультимедиа-помойки; jgthfwbjyrb могут быть разделены системами виртуализации.
>Но защитить программные каталоги от искажения разными хакерами и от случайностей надо. Приходится выносить /usr на отдельный раздел и монтировать его с Read-only.
Если хакер получил права, достаточные для записи в /usr, то ему хватит прав и перемонтировать его в rw. Это защита только от скриптинг-кидзов.
>Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
Угу. В /var могут находиться chroot для некоторых сервисов с копиями нужных для работы бинарников. Их тоже в отдельные от /var разделы выносить, чтобы они могли работать?
В /home в нормальных многопользовательских системах, например HPC, юзеры ходят по ssh в свои домашки и хотят запускать свой скомпиленный софт.
>swap, если нужен
Свап нужен всегда. Хотя бы на гиг-два. Спящие процессы предлагаете постоянно в памяти держать? Пусть лучше они в своп выгрузятся и отдадут свободную оперативку под файловый кеш.
Опять же, как уже писали неоднократно тут, — noexec это ни фига не защита. /bin/sh /tmp/backdoor.sh и по фигу ему на ваш флаг, или на stdin содержимое скрипта передать интерпретатору. Сейчас даже скрипт-кидзы запускают бюкдоры таким образом.
Если хакер получил права, достаточные для записи в /usr, то ему хватит прав и перемонтировать его в rw. Это защита только от скриптинг-кидзов.
>Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
Угу. В /var могут находиться chroot для некоторых сервисов с копиями нужных для работы бинарников. Их тоже в отдельные от /var разделы выносить, чтобы они могли работать?
В /home в нормальных многопользовательских системах, например HPC, юзеры ходят по ssh в свои домашки и хотят запускать свой скомпиленный софт.
>swap, если нужен
Свап нужен всегда. Хотя бы на гиг-два. Спящие процессы предлагаете постоянно в памяти держать? Пусть лучше они в своп выгрузятся и отдадут свободную оперативку под файловый кеш.
Опять же, как уже писали неоднократно тут, — noexec это ни фига не защита. /bin/sh /tmp/backdoor.sh и по фигу ему на ваш флаг, или на stdin содержимое скрипта передать интерпретатору. Сейчас даже скрипт-кидзы запускают бюкдоры таким образом.
По опыту могу сказать, что при переполнении /var/log многие сервисы перестают работать.
почти все. Но за логами надо следить отдельно и правильно настраивать само логирование, тогда никаких переполнений не будет.
А что Вы будете делать, если у Вас резко возрастет трафик и логи какого-нить nginx`а начнут занимать по 2-3 гига за день?
P.S. Усложняем задачу, по правилам работы все логи за все время существования сервера должны сохранятся и делать это на данном сервере ;)
P.S. Усложняем задачу, по правилам работы все логи за все время существования сервера должны сохранятся и делать это на данном сервере ;)
Согласен, только всегда нужно оценивать целесообразность. Если настолько критично — можно для логов отдельную СХД поднять.
Вам, очевидно, всегда везет с заказчиками :)
А у меня вот на одном проекте заказчик просто как-то ночью спросил вытянем ли мы 8 миллионов хитов в день, я ответил что должны и утром я получил этот трафик, то есть тупо нельзя было на ходу увеличить место под логи, справились конечно, даже не было особых проблем, но было очень неприятно видеть, как место улетает.
А у меня вот на одном проекте заказчик просто как-то ночью спросил вытянем ли мы 8 миллионов хитов в день, я ответил что должны и утром я получил этот трафик, то есть тупо нельзя было на ходу увеличить место под логи, справились конечно, даже не было особых проблем, но было очень неприятно видеть, как место улетает.
Фотка понравилась.
> Старайтесь выносить из корня в отдельные разделы /boot, /home, /tmp, /var.
Зачем выносить в отдельные разделы /var и /tmp?
Что за бредовый совет?
Зачем выносить в отдельные разделы /var и /tmp?
Что за бредовый совет?
/var — для защиты от нехватки места на рутовом разделе.
/tmp — для возможности использования нежурналируемой фс и своих опций монтирования.
Я же обосновал каждый отдельный раздел в статье.
/tmp — для возможности использования нежурналируемой фс и своих опций монтирования.
Я же обосновал каждый отдельный раздел в статье.
И что же такого страшного произойдет при нехватке места на рутовом разделе? В обоих случаях большинство служб отвалится все равно. ssh для решения проблемы можно будет использовать в обоих случаях.
/tmp вообще лучше через tmpfs или через файл монтировать.
На вкус и цвет все фломастеры разные. Каждый админ разбивает так как привык. Нет рекомендаций, которые бы всем подошли.
/tmp вообще лучше через tmpfs или через файл монтировать.
На вкус и цвет все фломастеры разные. Каждый админ разбивает так как привык. Нет рекомендаций, которые бы всем подошли.
UFO just landed and posted this here
На практике проверяли? Я неоднократно заходил по ssh на сервера, где закончилось свободное место и половина сервисов отваливалась. Допускаю, что при этом использовались 5%, зарезервированные в файловой системе под рута, т.к. ssh с правами рута работает и логи пишет.
Вы совершенно правы, в таких случаях юзается место зарезервированное под рута, именно поэтому его совсем в 0 уводить нельзя.
P.S. Это и мой ответ на вопрос выше, часто отвечать не могу.
P.S. Это и мой ответ на вопрос выше, часто отвечать не могу.
Уводить в 0 можно и даже нужно, но с умом. Зачем мне на файловом хранилище размером в 10Tb, замонтированном в /home, терять/держать 500 гиг в резерве под рута, когда он туда ни одного файла вообще не пишет?
Встречал варианты разбивки, когда большое хранилище не били, а использовали как есть. Опять же — смысл на 10Тб (объем тупо для примера) держать в резерве 500 гиг? Если файловую систему переполнили сервисы, пишущие под рутом, то что 500 гиг, что террабайт — не спасут. Достаточно оставить 0.1% или даже меньше, чтобы рут мог зайти и поправить ситуацию.
Итого: В ноль уводить надо там, где это действительно нужно, а на корневой ФС или /var — по ситуации можно уменьшить значение по умолчанию.
Встречал варианты разбивки, когда большое хранилище не били, а использовали как есть. Опять же — смысл на 10Тб (объем тупо для примера) держать в резерве 500 гиг? Если файловую систему переполнили сервисы, пишущие под рутом, то что 500 гиг, что террабайт — не спасут. Достаточно оставить 0.1% или даже меньше, чтобы рут мог зайти и поправить ситуацию.
Итого: В ноль уводить надо там, где это действительно нужно, а на корневой ФС или /var — по ситуации можно уменьшить значение по умолчанию.
Да я сам постоянно напоминаю всем, что 5% это зверски много, на вот если у Вас /var или даже /var/log отделен, на нем нужно оставлять хотя бы 0.5%, это спасет при переполнении
А в случае с /home можно и в 0, Вы совершенно правы.
Главная же беда в том, что очень многие просто не знают или забывают про эти 5%(а больше всего меня удивляет, что в /etc/mke2fs.conf не выставляют значения ниже в основных дистрибах)
А в случае с /home можно и в 0, Вы совершенно правы.
Главная же беда в том, что очень многие просто не знают или забывают про эти 5%(а больше всего меня удивляет, что в /etc/mke2fs.conf не выставляют значения ниже в основных дистрибах)
При заполнении корневого раздела действительно ничего страшного не должно произойти.
/var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.
Буквально на днях видел сервер у которого даже /sbin/shutdown был сломан из-за повреждения структуры файловой системы. Как раз всё было на одном разделе на RAID1.
/var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.
Буквально на днях видел сервер у которого даже /sbin/shutdown был сломан из-за повреждения структуры файловой системы. Как раз всё было на одном разделе на RAID1.
>/var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.
А смысл, если устройство все равно одно? Вот если на отдельный диск/массив, то да — однозначно лучше. В случае одного устройства получаем в комплекте с дополнительной ФС еще один набор мета-данных, которые надо читать и кешировать отдельно от основной ФС. Так что спорный вопрос. Интересно, есть где-нибудь реальные замеры — как эффективнее в плане скорости?
Раид раиду рознь. Встречал массив 0+1 на дешевом контроллере, где при вылете одного диска рассыпался весь массив. Я считаю, что надо юзать либо нормальные аппаратные контроллеры, а если на них нет денег, то нативный софтовый раид линукса.
А смысл, если устройство все равно одно? Вот если на отдельный диск/массив, то да — однозначно лучше. В случае одного устройства получаем в комплекте с дополнительной ФС еще один набор мета-данных, которые надо читать и кешировать отдельно от основной ФС. Так что спорный вопрос. Интересно, есть где-нибудь реальные замеры — как эффективнее в плане скорости?
Раид раиду рознь. Встречал массив 0+1 на дешевом контроллере, где при вылете одного диска рассыпался весь массив. Я считаю, что надо юзать либо нормальные аппаратные контроллеры, а если на них нет денег, то нативный софтовый раид линукса.
Если файловая система замонтирована RO или в нее никто не пишет, то вероятность ее логической поломки существенно снижается. Повторюсь — у меня буквально на прошлой неделе был сервер, у которого (софт)RAID1 целый, но файловая система (метаинформация) развалена. Ни RAID ни журнал ФС не спасли. Какова причина этого сбоя сказать трудно, но я уверен, что если бы /sbin не пострадал, то сервер наверняка прочекал бы /var и все работало бы дальше.
Честно говоря за 13 лет ни разу такого не было. Если система стоит не на массиве, то при деградации диска без разницы как смонтирована ФС. На системах с аппаратными raid-контроллерами или нативным софт-raid линуксов тоже такое не видел. А вот в полусофтовых контроллерах каких только барабашек не встречал.
Софт раид был родной линуксовый?
И как интересно вы спасете /sbin? Корневую ФС в RO монтировать — не проканает. /sbin вынести на отдельный раздел — тоже.
Софт раид был родной линуксовый?
И как интересно вы спасете /sbin? Корневую ФС в RO монтировать — не проканает. /sbin вынести на отдельный раздел — тоже.
Совет вовсе не бредовый. Обычно разносят те файловые системы, модели доступа к данным которых сильно отличаются из-за требований (скорость, надежность, отказоустойчивость, персистентность данных между ребутами, шифрование и/или integrity verification, et cetera). Различные требования в свою очередь диктуют, какие именно файловые системы и опции монтирования лучше подходят в каждом случае.
Я всегда размечаю /, swap, /boot и /home. Остальное для десктопа излишне.
LVM не использую, т.к. не приходится часто переразметку делать и не нашёл информации по тому, какой у него оверхед.
LVM не использую, т.к. не приходится часто переразметку делать и не нашёл информации по тому, какой у него оверхед.
Пратически на всех linux web и db серверах разбиваю только 2 раздела "/" и swap.
LVM — плюс одна точка отказа.
Только раз за много лет пришлось заюзать swap под noexec, а сам swap — файлом на fs.
LVM — плюс одна точка отказа.
Только раз за много лет пришлось заюзать swap под noexec, а сам swap — файлом на fs.
всегда разбиваю на /boot, / и /home
/boot — ext2, чтобы ядро быстрее грузилось, незачем грабу лезть в ext4/btrfs, да и изменяется на нем что-либо редко.
особого смысла выделять /tmp не вижу, проблема с noexec решается элементарно mount -o bind /tmp /tmp, mount -o remount,noexec /tmp. Разве что делать его на tmpfs.
/boot — ext2, чтобы ядро быстрее грузилось, незачем грабу лезть в ext4/btrfs, да и изменяется на нем что-либо редко.
особого смысла выделять /tmp не вижу, проблема с noexec решается элементарно mount -o bind /tmp /tmp, mount -o remount,noexec /tmp. Разве что делать его на tmpfs.
> Особой нужды в свопе на системах нынче нет.
Швоп — это ваша подушка безопасности.
Когда по какой-то причине память кончается, без швопа мы сразу теряем процессы убитыми (и не факт, что именно те, что породили проблему, зачастую OOMkiller убивает самый жирный процесс, например базу данных, после чего серверу становится сразу еще хуже — клиенты пытаются подлкючиться а без б.д. их запросы не обрабатываются.сюда же можно отнести время на восстановление скажем побившейся от такого базы данных, которое будет не моментальным). В случае швопа вы получаете очень заметные тормоза еще до того, как память кончится совсем, и у вас есть время 1) получить сигнал от мониторинга 2) корректно на него среагировать.
в общем для серверов швоп обязателен, хотя бы в минимальном объеме пары-тройки гигов.
Швоп — это ваша подушка безопасности.
Когда по какой-то причине память кончается, без швопа мы сразу теряем процессы убитыми (и не факт, что именно те, что породили проблему, зачастую OOMkiller убивает самый жирный процесс, например базу данных, после чего серверу становится сразу еще хуже — клиенты пытаются подлкючиться а без б.д. их запросы не обрабатываются.сюда же можно отнести время на восстановление скажем побившейся от такого базы данных, которое будет не моментальным). В случае швопа вы получаете очень заметные тормоза еще до того, как память кончится совсем, и у вас есть время 1) получить сигнал от мониторинга 2) корректно на него среагировать.
в общем для серверов швоп обязателен, хотя бы в минимальном объеме пары-тройки гигов.
Касательно свопа могу привести жизненный пример, высоконагруженная система, Solaris, процессоры SPARC64 VI всего 64-ядра, 130 Гб оперативной памяти и swap 16 Гб, казалось бы, куда уж больше, но в один момент при запланированном увеличении нагрузки на сервер Oracle начал выбрасывать ошибки с комментом out of memory и база начинала валиться. Пока я не создал дополнительный раздел Swap размером еще 16 Гб, oracle не успокоился. Так что для настоящих серверов 2-3 Гб маловато будет
Незабываем про fstab и, что лучше внести некоторые изменения для предотвращения нехороших действий.
Укажем где и что можно и нельзя делать системе (FreeBSD).
noexec – эта опция дает понять, что на данном разделе запрещено запускать что либо даже если права на файл chmod 777 (Я знаю что некоторые защищенные сервера ломали именно через /tmp :) в последствии админы советовали прикрывать эту дыру. И незабываем, что в /tmp может писать почти любой сервис в системе.
nosuid – при этом значении система игнорирует suid-биты. Юзер не сможет сделать
# su и подняться до рута, даже если он знает его пароль рута и находится в группе
wheel
nodev – запрещаем создание\существование в данном разделе специальных устройств.
Укажем где и что можно и нельзя делать системе (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 2noexec – эта опция дает понять, что на данном разделе запрещено запускать что либо даже если права на файл chmod 777 (Я знаю что некоторые защищенные сервера ломали именно через /tmp :) в последствии админы советовали прикрывать эту дыру. И незабываем, что в /tmp может писать почти любой сервис в системе.
nosuid – при этом значении система игнорирует suid-биты. Юзер не сможет сделать
# su и подняться до рута, даже если он знает его пароль рута и находится в группе
wheel
nodev – запрещаем создание\существование в данном разделе специальных устройств.
Было время когда своп выносился на отдельный диск.
И кстати /tmp я часто размещают в памяти для ускорения работы.
TMPFS — использование RAM в качестве tmp, что само собой разумеется, быстрей и эффективней чем, он бы располагался на HDD. TMPFS появился только в FreeBSD 7.0-RELEASE
И кстати /tmp я часто размещают в памяти для ускорения работы.
TMPFS — использование RAM в качестве tmp, что само собой разумеется, быстрей и эффективней чем, он бы располагался на HDD. TMPFS появился только в FreeBSD 7.0-RELEASE
собой нужды в свопе на системах нынче нет.
категорически не верно. своп необходим для эффективной работы механизма отбрасывания неиспользуемых страниц памяти.
Sign up to leave a comment.
Как и почему следует разбивать диск в никсах