Ну с тем софтом всем просто было — аналогов не было, писать свой — не вариант. На некоторых моделях машина в своп все-таки залезала, но на скорости расчетов особо не сказывалось это — перегнать пару гиг на SAS 15K не очень много времени занимает.
Идея виртуальной памяти — да, костыль. Но без него никуда. Он помогает в случае если нагрузки значительно превышают запланированные. Плюс помогает выгрузить из быстрой оперативной памяти те задачки, которые спят и тупо занимают оперативную память, которую можно потратить на более нужные вещи типа кеша.
Когда как. Иногда не костыль, а то без чего не получается работать. Встречались нам расчетные задачки, которые при запуске пытаются у системы отожрать 16 гиг, а реально стоит только 8. При том, в работе задача реально не использует больше половины запрошенной памяти. RHEL4 при таком поведении софта тупо склеивает ласты в kernel panic. Покупать память ради того, чтобы задача могла нормально запросить нужный объем и потом его реально в расчете не использовать, немного неразумно, особенно с учетом цены плашек для серверов. В данном случае не уверен, что это костыль :)
>/var/ выделяют в отдельный раздел, чтобы снять интенсивную запись с корневого раздела.
А смысл, если устройство все равно одно? Вот если на отдельный диск/массив, то да — однозначно лучше. В случае одного устройства получаем в комплекте с дополнительной ФС еще один набор мета-данных, которые надо читать и кешировать отдельно от основной ФС. Так что спорный вопрос. Интересно, есть где-нибудь реальные замеры — как эффективнее в плане скорости?
Раид раиду рознь. Встречал массив 0+1 на дешевом контроллере, где при вылете одного диска рассыпался весь массив. Я считаю, что надо юзать либо нормальные аппаратные контроллеры, а если на них нет денег, то нативный софтовый раид линукса.
Уводить в 0 можно и даже нужно, но с умом. Зачем мне на файловом хранилище размером в 10Tb, замонтированном в /home, терять/держать 500 гиг в резерве под рута, когда он туда ни одного файла вообще не пишет?
Встречал варианты разбивки, когда большое хранилище не били, а использовали как есть. Опять же — смысл на 10Тб (объем тупо для примера) держать в резерве 500 гиг? Если файловую систему переполнили сервисы, пишущие под рутом, то что 500 гиг, что террабайт — не спасут. Достаточно оставить 0.1% или даже меньше, чтобы рут мог зайти и поправить ситуацию.
Итого: В ноль уводить надо там, где это действительно нужно, а на корневой ФС или /var — по ситуации можно уменьшить значение по умолчанию.
>Но защитить программные каталоги от искажения разными хакерами и от случайностей надо. Приходится выносить /usr на отдельный раздел и монтировать его с Read-only.
Если хакер получил права, достаточные для записи в /usr, то ему хватит прав и перемонтировать его в rw. Это защита только от скриптинг-кидзов.
>Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
Угу. В /var могут находиться chroot для некоторых сервисов с копиями нужных для работы бинарников. Их тоже в отдельные от /var разделы выносить, чтобы они могли работать?
В /home в нормальных многопользовательских системах, например HPC, юзеры ходят по ssh в свои домашки и хотят запускать свой скомпиленный софт.
>swap, если нужен
Свап нужен всегда. Хотя бы на гиг-два. Спящие процессы предлагаете постоянно в памяти держать? Пусть лучше они в своп выгрузятся и отдадут свободную оперативку под файловый кеш.
Опять же, как уже писали неоднократно тут, — noexec это ни фига не защита. /bin/sh /tmp/backdoor.sh и по фигу ему на ваш флаг, или на stdin содержимое скрипта передать интерпретатору. Сейчас даже скрипт-кидзы запускают бюкдоры таким образом.
На практике проверяли? Я неоднократно заходил по ssh на сервера, где закончилось свободное место и половина сервисов отваливалась. Допускаю, что при этом использовались 5%, зарезервированные в файловой системе под рута, т.к. ssh с правами рута работает и логи пишет.
И что же такого страшного произойдет при нехватке места на рутовом разделе? В обоих случаях большинство служб отвалится все равно. ssh для решения проблемы можно будет использовать в обоих случаях.
/tmp вообще лучше через tmpfs или через файл монтировать.
На вкус и цвет все фломастеры разные. Каждый админ разбивает так как привык. Нет рекомендаций, которые бы всем подошли.
>Увы, logrotate не спасает от внезапного переполнения логов по вине форс-мажорного случая
Что мешает поставить newsyslog, добавить ограничения по размеру файлов и забыть про форс-мажор?
Точно. Если диск бякнется, то с ext2/3/4 еще можно данные вытащить ручками или спец-тулзами. С LVM их вытащить нереал, если только внезапно не появились тулзы, которые это умеют делать.
Перечитайте статью и поправьте чеклист :)
Забыли создание разделов и файловых систем, операции типа «изменения которые необходимы для того чтобы сервер загрузился».
Плюс. Конфигурять сеть через firstboot это сильно :) kudzu не устраивает? Хотя тоже хрень. Если на сервере больше одного интерфейса, то после первой загрузки будете долго перебирать интерфейсы пока все заработает. Проще заранее определиться что и где, и менять только HWADDR в ifcfg-ethX и modprobe.conf.
Платность KVM и отсутствие возможности грузить rescue по запросу у многих хостеров убивает всю последовательность действий. По крайней мере мне за всю практику попался только один хостер, который удовлетворял обоим условиям одновременно. Может это связано с тем, что сервера в основном в штатах у крупных хостеров. Там обезьянки на саппорте максимум что могут сделать — ребутнуть сервак, воткнуть квм или сделать реинсталл системы. Нормальные админы есть, но их хрен дождешься.
Плюс — повторный rsync надо запускать четко на нужные директории, т.к. если у нас имеется сервант, на котором лежит N террабайт контента и количество файлов 10^5-10^6, то эта команда будет работать часок-два.
Этот вариант описан как: «Обычно ставят на новую железку новую ОС, поднимают софт...». Имхо это самый правильный вариант, чем тащить на новый сервер старую ось.
Вот если локально переезжаем, то да — бывает проще dd'шкой перекинуть систему на новый сервер и поднять, чтобы меньше гемороиться и быстрее отвязаться от заказчика.
Если же тоже самое делать удаленно, то с большой вероятностью потребуется KVM, который далеко не у всех хостеров халявный и стоит ХХ баксов в час, а делить с хостером часть своего гонорара как-то не комильфо :)
Вообще если честно, всю эту длинную портянку из over 6000 пунктов можно заменить следующей последовательностью:
1. За 3-4 дня до конца месяца просим новый сервер у хостера. Как правило сервер меняется на более жирный и хостер соглашается эти 3-4 дня не биллить как полный месяц. Инсталл системы идет на шару, как правило, для нового сервера.
2. Дампим список пакетов с первого и нового серверов, удаляем версии и совпадения, подключаем нужные репы, доинсталиваем софт на новом сервере.
3. Делаем скриптик для rsync over ssh, подтягиваем /home, выборочно /var типа /var/lib/mysql, /var/mail, /var/named и т.п. на новый сервант.
4. Вытягиваем /etc, выбираем нужные конфиги типа апача, nginx, mysql и базу юзеров.
5. Стопим генерацию контента на время переезда, чтобы сократить время даунтайма и не заботиться об изменениях в /home. Стопим mysql и все службы на старом сервере, повторно синхрим изменения из нужных директорий /var.
6. Запускаем заранее сконфигуренный проброс портов на старом сервере и все службы на новом.
Из бонусов — получаем переезд с 3 на 4, с 4 на 5 или с 5 на 6 RHEL/CentOS. Т.к. апгрейд серверов обычно не так часто делается. В случае использования SELinux, добавляется пункт 5.1/2 — установка/восстановление контекстов на файлы.
С фряхой еще проще — если изначально все компоненты LAMP компилить в соответствующие директории /home, то пересобрать недостающие порты и скопировать кусок rc.local.
И пункт 7 — просим 30/31 числа загасить старый сервак, т.к. даже самые отмороженные днс-сервера кеш больше 3 дней не хранят, что заметно по трафу на старом серваке.
Сколько раз уже переезжал — даунтайм в пределах пары минут был. Максимум пару раз было 10-15.
Это почему интересно нельзя? Стандартная комбинация DNAT+SNAT, т.е. не через REDIRECT, он — да, только на локальной машине работает.
У такого способа только один минус — адрес источника теряем, но для контентной фермы по фигу REMOTE_ADDR клиента.
Если надо сохранить адрес клиента, то пробрасываем через nginx.
Если у нас фряха, у которой ядро собрано без фаерволов, модулей и т.п., то все тоже решается через что-нибудь типа rinetd.
Первый и третий способы использовал по одному разу, второй — основной рабочий на данный момент, т.к. чисто контентых ферм мало под управлением.
>Конечно то, что творится дальше на старом сервере не перенесётся на новый
Чтобы этого избежать достаточно на старом развернуть проброс портов нужных служб в iptables на соответствующие порты нового сервера. Либо тупо через nginx проксирование нужных хостов на старый сервер. Неоднократно так переезжали уже при апгрейде серверов и сменах каналов. Даун-тайм от силы минута на запуск двух команд.
Ухх! Ностальгия елки-палки. Если не ошибаюсь, это Lyra 2. У нас в свое время на радиолюбительской туче товарищ ее один постоянно крутил. С учетом того, что туча была на полянке в лесу, то комп и монитор работали от автомобильного аккумулятора — практически мобильный спектрум был в начале 90х :) А рядом на каждом дереве портянки со списками деталей и комплектуха типа флоповодов, висящая на гвоздиках, вбитых в деревья.
Мдя. Прикольные времена были… Атмосфера была суперская.
Ну явно же в правилах сказали — за Вас должен подписаться иностранный авторитет (типа вора в законе, скорее всего), т.е. он будет выступать гарантом того, что Вы свалите со всем баблом только после того, как поделитесь со всеми с кем надо.
Автор скорее всего имел в виду, что вкручивать сберегайки надо держась за цоколь, т.к. стекло у большинства таких ламп тонкое и хрупкое. Но опять же часть ламп сейчас делают в виде обычных ламп накаливания — скорее всего для того, чтобы не шокировать обывателя, и внутри у них скорее всего обычные трубки стеклянные. Их можно и не за цоколь вкручивать. Ну и бывает, что не в каждую люстру ввернешь лампу, держась за цоколь и приходится действовать аккуратно.
Идея виртуальной памяти — да, костыль. Но без него никуда. Он помогает в случае если нагрузки значительно превышают запланированные. Плюс помогает выгрузить из быстрой оперативной памяти те задачки, которые спят и тупо занимают оперативную память, которую можно потратить на более нужные вещи типа кеша.
А смысл, если устройство все равно одно? Вот если на отдельный диск/массив, то да — однозначно лучше. В случае одного устройства получаем в комплекте с дополнительной ФС еще один набор мета-данных, которые надо читать и кешировать отдельно от основной ФС. Так что спорный вопрос. Интересно, есть где-нибудь реальные замеры — как эффективнее в плане скорости?
Раид раиду рознь. Встречал массив 0+1 на дешевом контроллере, где при вылете одного диска рассыпался весь массив. Я считаю, что надо юзать либо нормальные аппаратные контроллеры, а если на них нет денег, то нативный софтовый раид линукса.
Встречал варианты разбивки, когда большое хранилище не били, а использовали как есть. Опять же — смысл на 10Тб (объем тупо для примера) держать в резерве 500 гиг? Если файловую систему переполнили сервисы, пишущие под рутом, то что 500 гиг, что террабайт — не спасут. Достаточно оставить 0.1% или даже меньше, чтобы рут мог зайти и поправить ситуацию.
Итого: В ноль уводить надо там, где это действительно нужно, а на корневой ФС или /var — по ситуации можно уменьшить значение по умолчанию.
Если хакер получил права, достаточные для записи в /usr, то ему хватит прав и перемонтировать его в rw. Это защита только от скриптинг-кидзов.
>Это /var, /home, /srv. Значит, их надо вынести и монтировать с noexec.
Угу. В /var могут находиться chroot для некоторых сервисов с копиями нужных для работы бинарников. Их тоже в отдельные от /var разделы выносить, чтобы они могли работать?
В /home в нормальных многопользовательских системах, например HPC, юзеры ходят по ssh в свои домашки и хотят запускать свой скомпиленный софт.
>swap, если нужен
Свап нужен всегда. Хотя бы на гиг-два. Спящие процессы предлагаете постоянно в памяти держать? Пусть лучше они в своп выгрузятся и отдадут свободную оперативку под файловый кеш.
Опять же, как уже писали неоднократно тут, — noexec это ни фига не защита. /bin/sh /tmp/backdoor.sh и по фигу ему на ваш флаг, или на stdin содержимое скрипта передать интерпретатору. Сейчас даже скрипт-кидзы запускают бюкдоры таким образом.
/tmp вообще лучше через tmpfs или через файл монтировать.
На вкус и цвет все фломастеры разные. Каждый админ разбивает так как привык. Нет рекомендаций, которые бы всем подошли.
Что мешает поставить newsyslog, добавить ограничения по размеру файлов и забыть про форс-мажор?
Забыли создание разделов и файловых систем, операции типа «изменения которые необходимы для того чтобы сервер загрузился».
Плюс. Конфигурять сеть через firstboot это сильно :) kudzu не устраивает? Хотя тоже хрень. Если на сервере больше одного интерфейса, то после первой загрузки будете долго перебирать интерфейсы пока все заработает. Проще заранее определиться что и где, и менять только HWADDR в ifcfg-ethX и modprobe.conf.
Плюс — повторный rsync надо запускать четко на нужные директории, т.к. если у нас имеется сервант, на котором лежит N террабайт контента и количество файлов 10^5-10^6, то эта команда будет работать часок-два.
Вот если локально переезжаем, то да — бывает проще dd'шкой перекинуть систему на новый сервер и поднять, чтобы меньше гемороиться и быстрее отвязаться от заказчика.
Если же тоже самое делать удаленно, то с большой вероятностью потребуется KVM, который далеко не у всех хостеров халявный и стоит ХХ баксов в час, а делить с хостером часть своего гонорара как-то не комильфо :)
1. За 3-4 дня до конца месяца просим новый сервер у хостера. Как правило сервер меняется на более жирный и хостер соглашается эти 3-4 дня не биллить как полный месяц. Инсталл системы идет на шару, как правило, для нового сервера.
2. Дампим список пакетов с первого и нового серверов, удаляем версии и совпадения, подключаем нужные репы, доинсталиваем софт на новом сервере.
3. Делаем скриптик для rsync over ssh, подтягиваем /home, выборочно /var типа /var/lib/mysql, /var/mail, /var/named и т.п. на новый сервант.
4. Вытягиваем /etc, выбираем нужные конфиги типа апача, nginx, mysql и базу юзеров.
5. Стопим генерацию контента на время переезда, чтобы сократить время даунтайма и не заботиться об изменениях в /home. Стопим mysql и все службы на старом сервере, повторно синхрим изменения из нужных директорий /var.
6. Запускаем заранее сконфигуренный проброс портов на старом сервере и все службы на новом.
Из бонусов — получаем переезд с 3 на 4, с 4 на 5 или с 5 на 6 RHEL/CentOS. Т.к. апгрейд серверов обычно не так часто делается. В случае использования SELinux, добавляется пункт 5.1/2 — установка/восстановление контекстов на файлы.
С фряхой еще проще — если изначально все компоненты LAMP компилить в соответствующие директории /home, то пересобрать недостающие порты и скопировать кусок rc.local.
И пункт 7 — просим 30/31 числа загасить старый сервак, т.к. даже самые отмороженные днс-сервера кеш больше 3 дней не хранят, что заметно по трафу на старом серваке.
Сколько раз уже переезжал — даунтайм в пределах пары минут был. Максимум пару раз было 10-15.
У такого способа только один минус — адрес источника теряем, но для контентной фермы по фигу REMOTE_ADDR клиента.
Если надо сохранить адрес клиента, то пробрасываем через nginx.
Если у нас фряха, у которой ядро собрано без фаерволов, модулей и т.п., то все тоже решается через что-нибудь типа rinetd.
Первый и третий способы использовал по одному разу, второй — основной рабочий на данный момент, т.к. чисто контентых ферм мало под управлением.
Чтобы этого избежать достаточно на старом развернуть проброс портов нужных служб в iptables на соответствующие порты нового сервера. Либо тупо через nginx проксирование нужных хостов на старый сервер. Неоднократно так переезжали уже при апгрейде серверов и сменах каналов. Даун-тайм от силы минута на запуск двух команд.
Мдя. Прикольные времена были… Атмосфера была суперская.