У меня есть несколько производственных серверов, на которых работает Centos. Мое приложение требует довольно свежую версию PHP (> 5.2, IIRC). В настоящее время пользователям Centos доступны следующие варианты:
Другие варианты:
Итак, в конце концов, мой вопрос таков: есть ли хороший источник стабильных, безопасных, регулярно обновляемых пакетов PHP или исходного кода (для ЛЮБОГО дистрибутива linux)? Откуда вы берете исходники / двоичные файлы?
Просто чтобы выделить сторону Debian:
Предыдущий выпуск Debian - Etch (8 апреля 2007 г.) - поставлялся с PHP 5.2.0.
Текущий выпуск Debian - Lenny (14 февраля 2009 г.) - поставляется с PHP 5.2.6.
Если в течение цикла выпуска должны быть какие-либо серьезные обновления пакетов, эти версии обычно доступны по адресу backports.org если у них есть заметная пользовательская база. Полный список поддерживаемых пакетов, доступных для Ленни, можно найти Вот. На данный момент этот список относительно короткий, поскольку последней версии всего несколько месяцев.
Чтобы увидеть конкретные версии для PHP и другие пакеты в Debian, которые вы можете использовать packages.debian.org.
Я создаю свои собственные RPM, потому что я не доверяю сторонним разработчикам оставаться на земле.
Это немного неудобно (хотя я создаю только несколько пакетов), но я знаю, что получу, когда закончу. Я использую файлы спецификаций из восходящего потока (RHEL / CentOS), но при необходимости изменяю их в соответствии с моими потребностями и заменяю его любой версией источника, который я ищу (изменяя патчи восходящего потока, если необходимо).
Это также помогает моему рабочему процессу не устанавливать компиляторы в производственные системы, поскольку я могу отправлять им свои специально созданные двоичные файлы. Я также делаю это, чтобы обеспечить резервные копии для новых пакетов для более старых ОС, когда я "застрял" в использовании более старой ОС (нет бюджета на обновление и т. Д.).
Если вы можете заполучить SRPMS, собрать пакет не так уж сложно. (Это в основном сбор среды сборки для данного пакета, что может быть проблемой.) Создание RPM из ничего (т.е. написание спецификации самостоятельно) - хорошее упражнение, хотя вам следует сначала прочитать некоторые «профессионально» сделанные specfiles, чтобы получить почувствуйте это.
Я не могу ответить на ваш вопрос, но я использую официальную версию исходного кода, а затем компилирую его в среде разработки.
Затем я просто создаю пакет из него с помощью инструмента dpkg (я использую debian), но должен быть аналогичный способ создания пакета с RedHat, например OS.
Затем вам просто нужно распространить его на своих серверах.
Другие варианты, которые стоит рассмотреть
Мы поддерживаем работающую виртуальную машину для сборки пакетов, недоступных в репозиториях дистрибутива. Это постоянная проблема при использовании дистрибутива; решение обычно состоит в том, чтобы создать их самостоятельно и быть в курсе рекомендаций по безопасности и утечек для этих пакетов. Исправления безопасности, которые распространяют производители, обычно сначала предоставляются через списки безопасности, затем они тестируются, интегрируются поставщиками и выпускаются.
Честно говоря, пока вы проверяете свой код с помощью gpg-ключа (а затем подписываете пакеты своим собственным ключом), вы будете в такой же безопасности, как и код дистрибутива. Вам просто нужно идти в ногу со временем, что небезопасно, это просто труд. Если вам нужна функциональность, то вам решать. В противном случае выберите дистрибутив, у которого нет проблем с конечной точкой, как у CentOS, или у которого есть официальная служба сборки (кашель OpenSuSE) или купите лицензию у поставщика, который обновляется чаще. Ты можешь работать, а можешь платить. Ваш выбор, но в пиве столько «бесплатного» ...
И идите пообщаться с некоторыми старыми грязными седыми волосами, которые с удовольствием расскажут вам, насколько трудоемко было поддерживать коробку, когда ВСЕ было скомпилировано из исходников. ;)