Цинізм в it вибір ос для хостингу centos або debian 5

Досить довгий час працюю з обома ОС в основному в контексті
"Хостинг-сервер". Раніше я схилявся до думки, що краще за все для
хостинг-серверів підходить CentOS 5 (тому що все ж це повноцінний
"Enterprise" дистрибутив з усіма наслідками, що випливають), але зараз впевненості
у мене поменшало. Тому я постараюся дати якомога більше
об'єктивне порівняння дистрибутивів якраз по якостям, які в
першу чергу важливі для хостингу.

Порівняння буде виконуватися в наступному оснащенні дистрибутивів:
Debian - тільки базовий репозиторій, CentOS - тільки базовий і Epel
репозиторії (я б його теж відніс до "стандартним", тому що працювати в
CentOS без нього майже неможливо).

Для початку давайте згадаємо, що таке хостинг і з якого ПО він складається.

хостингових ПО
По-перше, це звичайно ж Apache, який виконує левову частку
роботи на хостингу і є стандартом де-факто (здебільшого
завдяки усіма коханому mod_rewite і .htaccess). Тут відмінності знайти
складно, обидва дистрибутива мають 2.2 версію Apache і цілком стабільно
працюють. Так що тут рівноцінно.

Крім Апача для зниження навантаження (і, до речі, в якомусь роді захисту від
DoS при обмежених ресурсах сервера) і роздачі статики часто
використовується Nginx - актуальна версія в CentOS: 0.6.39, Debian:
0.6.32. До слова, обидві ці версії мають баг (він виправлений тільки в 0.7,
см. розсилку nginx-ru) при якому при усечении конфіга nginx.conf
(Проявляється таке, наприклад, в досить популярною панелі ISPManager)
Nginx з'їдає всю пам'яті і система просто-напросто висне. Так що тут
обом мінус і доведеться самому збирати пакет і ставити Nginx 0.7.

Для повноцінної взаємодії Nginx і Apache, тобто для коректної
передачі IP бекенда необхідний модуль Апача - rpaf, який
переглядає отриманий від Nginx IP і передає його Апач. цей модуль
відсутня навіть в репозиторії Epel CentOS`а (зараз я його беру в
CentAlt), але в той же час, в Debian він є стандартно. що також
додає переваг саме Debian`у.

Тепер про головне, про PHP, адже це фактично причина використання
всього іншого хостингового ПО, бо переважна кількість CMS
написано саме на ньому (прошу вибачення у любителів Python, Perl і
Ruby, а також інших мов, але статистика споживчого шаред
хостингу говорить про тотальне кількісному перевазі PHP).

Тут-то і починаються проблеми у CentOS, по-перше, на ньому стоїть PHP
5.1.6, а багато ПО (наприклад, Magento - дуже популярний веб-магазин)
вимагає саме 5.2 версію і якщо ви не хочете мати справу з великою
числом скарг від клієнтів через непрацездатності скриптів, Ви
будете змушені або підключати сторонні репозиторії (які мало
того, що не гарантують стабільності ПО і коректності його збірки, а
в гіршому випадку - навіть не відповідають вимогам безпеки і
надійності), або збирати PHP 5.2 самостійно з усіма модулями
(Що знову ж зробити не так тривіально, враховуючи число модулів в
репозиторіях - в Debian це, наприклад, близько 50 штук). А якщо ще
згадати, що для PHP досить часто виходять виправлення
безпеки, то доведеться весь цей комплект оперативно патчить,
збирати в пакети і розносити по серверами, то завдання вже здається
майже нездійсненним.

Також варто згадати баг php-cgi в CentOS через якого він не читає
php.ini в цій папці, коли він присутній і все одно йде в
/etc/php.ini, що сильно заважає його роботі в режимі php-fastcgi (в
Debian ж з цим все ок). В Debian варто 5.2.6 версія PHP з патчем
suhosin, який значно збільшує безпеку скриптів і
дозволяє запускати майже всі без винятку сучасні двигуни.

Далі пройдемо по пропрієтарним модулів для PHP, які використовуються
для захисту скриптів - це Zend Optimizer і IonCube. Що перший, що
другий поставляються в збірках і під PHP 5.1 і під 5.2. Так що і з
ними ніяких проблем не буде.

MySQL, обидва дистрибутива містять 5.0 версію з усіма необхідними
опціями. Стабільною ж (на думку Sun Microsystems) є 5.1, але
ні в одному дистрибутиві її ще "не визнали" по-справжньому стабільної
та й ПО, яке вимагає тільки 5.1 версію я не бачив ще жодного разу.

Postfix, Exim, Sendmail - все три поштовика представлені в обох
дистрибутивах. Причому, до слова, postfix-mysql знаходиться в стандартному
репо Debian, в той час як в CentOS він ставиться досить нетривіально,
але це лише опція і в явні переваги записувати не будемо.

Тепер поговоримо про версії хостингової екзотики - Perl, Python і Ruby.
У CentOS присутній тільки 2.4 версія мови, а в Debian 2.5, так
що для любителів нових можливостей тут, мабуть вибір однозначний. З
Ruby вибір трохи більше - в Debian присутній і 1.8 і 1.9 версії, а
в CentOS тільки 1.8.5. Perl ж в Debian наймоднішою версії - 5.10, в
CentOS ж перевірений часом (і лінгвістами :) 5.8.8.

Управління ПО: установка і оновлення
Тут у обох дистрибутивів справи йдуть досить добре, як я вже
говорив вище, для CentOS існує відмінний сторонній репозиторій зі
багатьма необхідними пакетами - Epel (є частиною проекту Fedora),
а у Debian навіть без додаткових репозиторіїв вибір пакетів дуже
великий. Для встановлення та оновлення програм в CentOS використовується
YUM, що відрізняється щодо неекономним ставленням до пам'яті, але при
цьому він не завалює користувача питаннями про конфігурацію пакетів,
як це робить пакетний менеджер Debian - apt-get.

Різні способи запуску ОС
З приводу роботи на "чистому залозі" (виділений, dedicated сервер або
colocation) варто віддати перевагу все ж Debian, тому що у нього ядро
новіше, ніж у CentOS (так, Ви можете заперечити, що RH оперативно
бекпортіт підтримку обладнання, але все ж мій досвід говорить про те,
що з Debian при роботі на залозі проблем набагато менше, ніж c
CentOS).

Окремим пунктом, думаю, варто відзначити стабільність роботи в
віртуальних середовищах OpenVZ і Xen. Обидва дистрибутива працюють відмінно
і будь-яких нарікань і проблем не мають, що дуже важливо, враховуючи
популярність VPS хостингів і Cloud платформ (наприклад, Amazon EC2).

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

За версіями пакетів, це якось не те порівнювати. Пакети це як-б не постійне. Що в дебьяне можна підключити роднодной, але новіший реп, так подібно можна в сент.
Чи не могли б ви дати порівняння на рівні "інтерфейсів".
Наприклад як сказано було, що в / etc зберігаються конфіги у Деба.

кст, в пості сказано було про велику кількість питань aptitude. на скільки знаю, можна змінити рівень debconf?

Пакети порівнювалися бо йшло порівняння конкретних версій дистрибутивів з мінімальним використанням зовнішніх репо.

З приводу конфігов, у Деби вони набагато зручніше, наприклад, замість монолітного /etc/php.ini присутній ціла папка конфігов, які можна зручно контролювати і редагувати, те ж саме відноситься до /etc/sysctl.conf.d, / etc / mysql / conf.d

Щодо debconf не морочився - не знаю, все ж іноді ці повідомлення дуже допомагають, тому я з ними звикся.

Схожі статті