Как бороться с частыми и постоянными обновлениями версий PHP / MySQL

Эта проблема:

Я знаю, что многие люди не очень довольны частой сменой версий. Особенно, когда последняя версия PHP или MySQL, которой вы придерживаетесь, больше не доступна в вашем репозитории (в моей ситуации это REMI), но вам нужно установить новый сервер с некоторыми пакетами PHP / MySQL версии немного ниже ( старше / ранее) из того, что доступно в репозитории.

В большинстве случаев мы используем последнюю версию типичного Apache, PHP, MySQL поверх операционной системы Centos 5.8 GNU / Linux x86_64.

Но теперь нашей команде QA требуется много времени, чтобы протестировать все наши проекты на совместимость с новыми версиями, которые появляются так быстро, что в то время у нас есть зеленый свет от группы QA для обновления PHP и / или MySQL и / или установки новый сервер с этой конкретной версией, мы обнаруживаем, что он уже устарел, и теперь он заменен более новой версией.

Это особенно радует, когда McAfee PCI Compliance заявляет, что наши сайты используют потенциально опасную версию PHP, и вынуждает нас обновлять все серверы на более новую версию PHP.

В настоящий момент наша рабочая среда по умолчанию состоит из следующих парней:

ОПЕРАЦИОННЫЕ СИСТЕМЫ:

Выпуск CentOS 5.8 (окончательный) Linux censored.example.com 2.6.18-308.4.1.el5 # 1 SMP Вт, 17 апреля 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU / Linux

Apache:

Версия сервера: Apache / 2.2.3 Сервер построен: 23 февраля 2012 г. 21:16:56

PHP:

PHP 5.3.13 (cli) (построено: 9 мая 2012, 16:20:57) Copyright (c) 1997-2012 PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies с eAccelerator v0.9.6. 1, Copyright (c) 2004-2010 eAccelerator, автор: eAccelerator

MySQL:

mysql Ver 14.14 Distrib 5.5.23, для Linux (x86_64) с использованием readline 5.1

Возможные решения:

Локальный репозиторий / Зеркало старых версий Просто сделайте пользовательский снимок последних установленных пакетов, чтобы мы могли настроить / установить новые серверы с такими же пакетами, даже если они больше не поддерживаются, прежде чем мы будем готовы двигаться дальше. Плюсы и минусы: простая установка с использованием тех же команд YUM, но не нарушит ли это зависимости от других системных пакетов, которые могут быть обновлены, есть ли скрытые водяные камни таким образом?
Скомпилировать из исходного кода Забудьте о YUM и RPM и вернитесь в старые добрые времена с компилятором GCC и адом зависимостей, используя статически скомпилированные версии. Плюсы и минусы: больше не зависит от изменений версий репозитория (или я все еще могу косвенно?), Но мне придется получить весь исходный код вручную и иметь какое-то управление этим материалом.
Создание и использование собственного изображения Просто создайте и сконфигурируйте подходящий сервер, сделайте его моментальный снимок (в виде виртуальной машины или физического ISO-образа HD), а затем просто разверните его образ на новом физическом сервере или импортируйте виртуальную машину на хост визуализации. Плюсы и минусы: Разумеется, больше нет проблем с изменениями версий и зависимостями, но насколько это надежно? Да, это проще простого, если мы говорим о виртуальных машинах, но какое-то время нам нужно развертывать проекты на физических машинах, у которых нет ничего, кроме доступа по SSH.
Принять обновления, если это только незначительное изменение версии Не беспокойтесь об исправлениях ошибок и изменениях версий, так как исправлены критические проблемы безопасности, количество которых увеличивается. Просто обновите их как можно скорее. За и против: McAfee PCI Compliance наверняка будет довольна, как и наши клиенты, но разве это не опасно? Что, если это было незначительное изменение значений конфигурации PHP по умолчанию, которое мы не заменили? Разве это не будет полной катастрофой?

Есть предложения, уважаемые специалисты?

Хорошо - так что давайте свяжемся с этим:

Основная проблема, с которой вы сталкиваетесь, заключается в том, что вам необходимо запустить более новую версию PHP / MySQL, но к тому времени, когда ваша группа QA протестирует программное обеспечение в новой системе, эта версия устарела.

Это не ошибка вашей команды; это ошибка команды QA.

У вашей команды QA должны быть автоматизированные тестовые случаи. Ваши разработчики должны предоставлять тестовые модули по мере их продвижения. Например.:

Разработчик строит пропорциональную систему выставления счетов
Разработчик предоставляет тестовый интерфейс для про-рейтинга (т.е. принимает все детали, необходимые для тестирования системы, но фактически не генерирует счет. Или, может быть, это так, но в промежуточной системе).
Команда QA разработала серию тестов для проверки этой рутины. Что это за ввод и что это за верный результат? Например. 50 долларов в месяц пропорционально на полмесяца == 25 долларов.

Этот последний шаг должен быть полностью автоматизирован. Определение любых ошибок должно занять несколько минут или часов (в зависимости от сложности программного обеспечения или количества тестов). НАПРИМЕР.

PHP изменяет математику с плавающей запятой с обычного округления на cieling (всегда округляется в большую сторону)
Тестовый кейс прорейтинга 5 $ / мес на полмесяца
Правильный ответ: 2,50 доллара, но тестовый пример возвращает 3 доллара. Автоматический сбой.

Я знаю, что ничто из этого на самом деле не отвечает на ваш вопрос, поэтому, если ваша команда QA не может быть исправлена, то каковы другие варианты:

На это нет однозначного правильного ответа. Лично то, что мы делаем с нашим программным обеспечением, - это ваш последний вариант: мы принимаем все обновленные и сервисные пакеты для наших сред выполнения, но мы не меняем версии без тщательного и полного анализа качества. Хотя программное обеспечение, которое мы используем в наших средах выполнения (то есть MSSQL и другой бэкэнд, а не PHP), выпускает новые версии только каждые 18 месяцев - 2 года с обновлениями и пакетами обновлений между ними, поэтому между основными развертываниями много времени.

После тестов QA в наших промежуточных системах мы развертываем обновление на нашем системы кормов для собак первый. Если мы не обнаружим серьезных проблем, мы выкатываем обновления среды выполнения в наши размещенные системы. Если у нас по-прежнему нет серьезных проблем, мы выпускаем уведомления для наших клиентов, размещенных на собственном хостинге, о том, что они могут установить обновления, если захотят.

Лично я съеживаюсь каждый раз, когда получаю готовую виртуальную машину. Даже если он полностью обновлен (а они никогда не обновляются, как вы отметили), мне нужно поработать над интеграцией в нашу сеть. А иногда они поставляются с ужасно устаревшими операционными системами или средами выполнения.

Вы задали свой вопрос следующим образом:

Периодически критические недостатки безопасности обнаруживаются в компонентах вашего серверного стека, включая PHP и MySQL.
Когда такие недостатки обнаруживаются, разработчики PHP и MySQL выпускают новые версии. В интересах безопасности старые / небезопасные версии могут больше не быть доступны в репозиториях, которые вы используете.
Ваше веб-приложение должно соответствовать стандарту PCI. Когда вы используете старые небезопасные версии PHP и MySQL, ваше веб-приложение не проходит сканирование безопасности PCI, которое необходимо пройти для обеспечения соответствия.
Вы никогда не сможете использовать текущую версию со всеми исправлениями безопасности, потому что вашей команде QA требуется «много времени» (очевидно, месяцы), чтобы дать зеленый свет на использование каждой версии безопасности PHP и MySQL. Фактически, они так долго ждут утверждения обновлений безопасности, что вы никогда полностью пропатчен.

Затем вы перейдете к изучению различных возможностей для упрощения установки старых версий PHP и MySQL с известными уязвимостями. Тем не мение, элементы № 1-3 выше не подлежит обсуждению.

Пункт №4, с другой стороны, является договорная. Ergo, Команда QA вашей компании - это проблема. Обновления безопасности, увеличивающие номер версии на 0,0.1 (например, с PHP v5.4.2 на v5.4.3), являются очень вряд ли сломает ваше приложение.

Вам следует установить новую версию в своей тестовой среде, запустить автоматические тесты, выполнить минимальное ручное тестирование, а затем развернуть его. Как и в случае с любыми другими изменениями, вам необходимо иметь план действий на случай непредвиденных проблем, но ... да ладно, вы говорите о патчах для известных эксплойтов! Риск безопасности, который вы берете на себя не установка исправлений (которая, кстати, включает гарантированный сбой ваших сканирований на соответствие PCI) далеко превышает любой риск, на который вы берете исправления.

Обновление функций (например, с PHP v5.3.x до v5.4.x) может потребовать более тщательного тестирования, и по уважительной причине: например, из 5.4.0 были удалены различные устаревшие функции, а некоторые старые приложения, возможно, потребуется обновить соответствующим образом. К счастью, вы на самом деле делать получите месяцы на тестирование этих выпусков. Именно поэтому обновления безопасности предоставляются одновременно как для текущей, так и для предыдущей версии.

Это ужасно похоже на то, что ваша команда QA путает мелкие обновления безопасности с фактическими обновлениями функций.

Управляющее резюме:

Безопасность обновления, которые не добавляют / не удаляют функции, должны применяться немедленно с минимальным тестированием. это неприемлемый чтобы процессы вашей компании подвергали мелкие обновления безопасности бюрократическим проволочкам, если только актуальные проблемы обнаруживаются при первоначальном тестировании.
Когда дело доходит до характерная черта выпуски, которые имеют гораздо более высокую вероятность выхода из строя устаревших приложений, ваша команда QA может и дальше не торопиться.