С 2010 года, когда я только начал заниматься системным администрированием, я использовал как основной серверный дистрибутив Debian. Это был изначально осознанный выбор, и на момент написания заметки таковым и остается. Конечно, я работал и с другими дистрибутивами, и потому мне есть и было с чем сравнить. По итогам работы с Debian и написана эта заметка.
#Негатив
##Общесистемные лимиты
В свое время, встала передо мной задача настройки под высокую нагрузку различных сервисов,
в том числе PostgreSQL + pgbouncer. И конечно мне надо было подтюнить лимит количества
открытых файлов для пользователя postgres, что я и попытался сделать, отредактировав
/etc/security/limits.conf. Но толку с этого не было, cat /proc/$PID/limits показывал
в строке Max open files все то же значение - 1024 файла, хотя ulimit -n от пользователя
Postgres показывал корректное значение (после su - postgres)
Я, был удивлен, и полез разбираться. Для начала - в /etc/pam.d
Там я обнаружил, что отсутствует строчка
session required pam_limits.so
в настройках для новой сессии везде, кроме настроек для su.
Я эту строчку добавил для всех сессий, ради эксперимента.
Но толку не было - сервисы запускались все так же с лимитом 1024.
Я полез разбираться дальше,и вот что выяснил: Лимиты применяются с помощью модуля pam_limits, и отлично работают при выполнении через su - username, однако при инициализации через start-stop-daemon лимиты не выставляются, поскольку start-stop-daemon не использует pam. Сам start-stop-daemon - это Debian-специфичная вещь, представляет собой скрипт для запуска демонов, изначально написанный на Perl, а затем переписанный на C для ускорения. Что интересно, в RHEL6 и производных тоже используется свой инструмент для запуска демонов, но у них он основан на su и использует pam. В 2005 году по этому поводу был предложен патч, однако его так и не внесли в поставляемую версию start-stop-daemon. Также предлагались подобные патчи, основанные на инициализации сессии pam, и каждый раз отклонялись.
##Поломанный update-rc.d start/stop/defaults
В squeeze поломали update-rc.d start/stop/defaults, из-за чего не пашет disable service в chef. В puppet это обошли, а вот в chef - нет, так что пришлось патчить chef-client.
##Race condition в скриптах initramfs
Крайне милый баг в squeeze, из-за которого держать рут на LVM опасно. Патч предложен в 2010, до сих пор не включен в апстрим, версия 6.0.7 все так же может не найти LVM тома при загрузке. У меня, к счастью, проявился только на некотором железе, которое пришло под новый проект, и дождалось выхода wheezy, в котором такой проблемы вроде нет.
##Инертное коммьюнити, в которое очень непросто пробиться
Как можно заметить из предыдущих минусов, многие важные баги просто не хотят править, даже при наличии патчей. Если мейнтейнер конкретной области решит, что ваша проблема не стоит внимания - шансов на исправление крайне мало.
#Позитив
##Пакетная база
Безусловно, пакетная база Debian - это огромный плюс. Несмотря на то, что собрать нужный пакет под тот же RHEL6 не составляет труда, гораздо проще, когда этим за тебя занимаются другие люди, следящие за обновлениями.
Относительная стабильность
Несмотря на все недостатки и серьезные баги, система весьма стабильна, обновления хорошо тестируются, и проблем в эксплуатации не приносят. Тут, на мой взгляд, единственный конкурент Debian - это RHEL и его производные. Ключевое ПО все равно приходится ставить с репозиториев разработчиков, так что общая замшелость не является недостатком.