вопрос по ред хату.
Re: вопрос по ред хату.
leave, я ставлю Debian и производные без KVM и даже без serial console, был бы только отдельный раздел или LV мегабайт на 200, и при должно аккуратности в этом нет никакой технической проблемы.
Опыт растет прямо пропорционально выведенному из строя оборудованию
-
- Неотъемлемая часть форума
- Сообщения: 1055
- Зарегистрирован: 25 окт 2006, 14:50
- Откуда: minsk
- Контактная информация:
Re: вопрос по ред хату.
Llama, ну да, можно и поизвращаться - только смысл, если делаешь сервачок для недохостинга?
-
- Неотъемлемая часть форума
- Сообщения: 279
- Зарегистрирован: 23 апр 2005, 21:13
- Откуда: minsk
Re: вопрос по ред хату.
этого достаточно для удаленной переустановки линуксаleave писал(а):swap
Re: вопрос по ред хату.
leave, потому что проще один раз поставить нормальную ОС, чем потом сношатся с отслеживанием и ручным обновлением значительного количества компонент отсутствующих в дистрибутиве.
Опыт растет прямо пропорционально выведенному из строя оборудованию
- GnoM
- Фанатеющий
- Сообщения: 120
- Зарегистрирован: 05 фев 2009, 14:13
- Откуда: от туда
- Контактная информация:
Re: вопрос по ред хату.
Полностью согласен. И в этом отношении Дебиан, пожалуй, наиболее универсальный инструмент.Llama писал(а):leave, потому что проще один раз поставить нормальную ОС, чем потом сношатся с отслеживанием и ручным обновлением значительного количества компонент отсутствующих в дистрибутиве.
Я с удовольствием послушаю о ваших подвигах, когда закончу пИсать, спасибо.
-
- Неотъемлемая часть форума
- Сообщения: 484
- Зарегистрирован: 19 ноя 2007, 15:01
- Контактная информация:
Re: вопрос по ред хату.
неужели в centos все так плохо с обновлениями?Llama писал(а):leave, потому что проще один раз поставить нормальную ОС, чем потом сношатся с отслеживанием и ручным обновлением значительного количества компонент отсутствующих в дистрибутиве.
Two of the most famous products of Berkeley are LSD and BSD:)
Re: вопрос по ред хату.
Ларин, в 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 и не напрягаться насчет задержки обновлений - все работает стабильно и относительно предсказуемо.
Все вышеприведеные примеры - это за апрель текущего года.
Я специально не касаюсь вопросв внутренного устройства дистрибутива, ибо это совсем уж религиозно.
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 и не напрягаться насчет задержки обновлений - все работает стабильно и относительно предсказуемо.
Все вышеприведеные примеры - это за апрель текущего года.
Я специально не касаюсь вопросв внутренного устройства дистрибутива, ибо это совсем уж религиозно.
Опыт растет прямо пропорционально выведенному из строя оборудованию
Re: вопрос по ред хату.
Выбор хостеров обычно ограничен дистрибутивами, которые рекомендует разработчик их любимого хост менеджера CPanel. А это - Red Hat® or CentOS.leave писал(а):Llama, однако ж 90% дедик-хостеров дает на выбор центось, винду и сусю 10. редко-редко бывает дебиан/убунту. а после недавнего секса с мускулом на сусе я ее вообще не воспринимаю иначе как дистр для десктопа.
http://twiki.cpanel.net/twiki/bin/view/ ... ationGuide
И, соответственно, даже если это VPS или dedicated, хостер все равно в первую очередь предложит данные дистрибутивы, т.к. его support team привык работать именно с ними.
-
- Неотъемлемая часть форума
- Сообщения: 1055
- Зарегистрирован: 25 окт 2006, 14:50
- Откуда: minsk
- Контактная информация:
Re: вопрос по ред хату.
а что, сипанель уже фряху не поддерживает?
з.ы. имелись в виду в основном unmanaged сервера, ибо только ими интересуюсь.
з.ы. имелись в виду в основном unmanaged сервера, ибо только ими интересуюсь.
-
- Неотъемлемая часть форума
- Сообщения: 484
- Зарегистрирован: 19 ноя 2007, 15:01
- Контактная информация:
Re: вопрос по ред хату.
из соурсов ставить изврат:)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 и не напрягаться насчет задержки обновлений - все работает стабильно и относительно предсказуемо.
Все вышеприведеные примеры - это за апрель текущего года.
Я специально не касаюсь вопросв внутренного устройства дистрибутива, ибо это совсем уж религиозно.
поддерживать такое просто ужос.
но тебя я понял. спасибо за объяснение.
Two of the most famous products of Berkeley are LSD and BSD:)
-
- Неотъемлемая часть форума
- Сообщения: 484
- Зарегистрирован: 19 ноя 2007, 15:01
- Контактная информация:
Re: вопрос по ред хату.
поддерживает.leave писал(а):а что, сипанель уже фряху не поддерживает?
з.ы. имелись в виду в основном unmanaged сервера, ибо только ими интересуюсь.
Two of the most famous products of Berkeley are LSD and BSD:)