Linux.by

leave, я ставлю Debian и производные без KVM и даже без serial console, был бы только отдельный раздел или LV мегабайт на 200, и при должно аккуратности в этом нет никакой технической проблемы.

Llama, ну да, можно и поизвращаться - только смысл, если делаешь сервачок для недохостинга?

leave писал(а):swap

этого достаточно для удаленной переустановки линукса

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

Llama писал(а):leave, потому что проще один раз поставить нормальную ОС, чем потом сношатся с отслеживанием и ручным обновлением значительного количества компонент отсутствующих в дистрибутиве.

Полностью согласен. И в этом отношении Дебиан, пожалуй, наиболее универсальный инструмент.

Llama писал(а):leave, потому что проще один раз поставить нормальную ОС, чем потом сношатся с отслеживанием и ручным обновлением значительного количества компонент отсутствующих в дистрибутиве.

неужели в centos все так плохо с обновлениями?

Ларин, в CentOS есть три порблемы:

1) Апдейты из RHEL переносятся с заметной задержкой. Udev пролеченый от local root exploit появился только через три дня обнаружения дыры, а багфиксы не свзяаные с безопастностью пояляются только после вызода RHEL 5 Update X, в то время как пользователям RHEL они доступны сразу через RHN. У меня из-за бага в RPM вышла из строя система управления серверами - пришлось руками собирать srpm от RHEL и ставить её на все сервера с CentOS. Ответ разработчиков: "мы пофиксим rpm после того как RH выкатит Update 3 - т.е. в CentOS 5.3"

2) Значительная часть ПО присутсвующая в Debian и его производных в репозитариях CentOS отсуствует. Кое-то находится в сторонних репозитариях, в которых нет ни жесткого цикла тестирования как в RHEL, ни гарантий своервеменного их обновления, да и не известно сколь долго оно будет существовать. Extras + EPEL + Dag - все равно меньше чем main+contrib+non-free. В результате кое-что приходится ставить просто из исходников и затем следить и своевременно из исходников же обновлять. Особенно это касается php и perl модулей.

3) Уровень качества сторонних репозитариев - отдельная пестня. Скажем, обновившись однажды из EPEL, изменилось значение PATH при запуске служебных скриптов openvpn'ом - оттуда пропал /sbin . Как следствие - посреди рабочего дня почти час я угадывал, почему же не работает связь между офисами - вызов iptables в скриптах не оказывал никакого эффекта...

Если ограничится только софтом из CentOS Base и не напрягаться насчет задержки обновлений - все работает стабильно и относительно предсказуемо.
Все вышеприведеные примеры - это за апрель текущего года.
Я специально не касаюсь вопросв внутренного устройства дистрибутива, ибо это совсем уж религиозно.

leave писал(а):Llama, однако ж 90% дедик-хостеров дает на выбор центось, винду и сусю 10. редко-редко бывает дебиан/убунту. а после недавнего секса с мускулом на сусе я ее вообще не воспринимаю иначе как дистр для десктопа.

Выбор хостеров обычно ограничен дистрибутивами, которые рекомендует разработчик их любимого хост менеджера CPanel. А это - Red Hat® or CentOS.
http://twiki.cpanel.net/twiki/bin/view/ ... ationGuide
И, соответственно, даже если это VPS или dedicated, хостер все равно в первую очередь предложит данные дистрибутивы, т.к. его support team привык работать именно с ними.

а что, сипанель уже фряху не поддерживает?
з.ы. имелись в виду в основном unmanaged сервера, ибо только ими интересуюсь.

Llama писал(а):Ларин, в CentOS есть три порблемы:

1) Апдейты из RHEL переносятся с заметной задержкой. Udev пролеченый от local root exploit появился только через три дня обнаружения дыры, а багфиксы не свзяаные с безопастностью пояляются только после вызода RHEL 5 Update X, в то время как пользователям RHEL они доступны сразу через RHN. У меня из-за бага в RPM вышла из строя система управления серверами - пришлось руками собирать srpm от RHEL и ставить её на все сервера с CentOS. Ответ разработчиков: "мы пофиксим rpm после того как RH выкатит Update 3 - т.е. в CentOS 5.3"

2) Значительная часть ПО присутсвующая в Debian и его производных в репозитариях CentOS отсуствует. Кое-то находится в сторонних репозитариях, в которых нет ни жесткого цикла тестирования как в RHEL, ни гарантий своервеменного их обновления, да и не известно сколь долго оно будет существовать. Extras + EPEL + Dag - все равно меньше чем main+contrib+non-free. В результате кое-что приходится ставить просто из исходников и затем следить и своевременно из исходников же обновлять. Особенно это касается php и perl модулей.

3) Уровень качества сторонних репозитариев - отдельная пестня. Скажем, обновившись однажды из EPEL, изменилось значение PATH при запуске служебных скриптов openvpn'ом - оттуда пропал /sbin . Как следствие - посреди рабочего дня почти час я угадывал, почему же не работает связь между офисами - вызов iptables в скриптах не оказывал никакого эффекта...

Если ограничится только софтом из CentOS Base и не напрягаться насчет задержки обновлений - все работает стабильно и относительно предсказуемо.
Все вышеприведеные примеры - это за апрель текущего года.
Я специально не касаюсь вопросв внутренного устройства дистрибутива, ибо это совсем уж религиозно.

из соурсов ставить изврат:)
поддерживать такое просто ужос.
но тебя я понял. спасибо за объяснение.

leave писал(а):а что, сипанель уже фряху не поддерживает?
з.ы. имелись в виду в основном unmanaged сервера, ибо только ими интересуюсь.

поддерживает.