Деплой vBulletin в 2015 году

Собственно, недавно пришлось столкнуться с такой напастью, отсюда возник вопрос к профессионалам: А как вы, собственно, деплоите vBulletin в 2015 году? Помнится раньше все было относительно просто, в ubuntu server 12.04 поставлялся пакет php5, предоставляющий интерпретатор php версии 5.3, на котором vBulletin пусть худо-бедно, пусть с error.log в три раза большим, чем acсess.log, но все же как-то запускался. Это, конечно, ужасно, но хотя бы работало и позволяло запустить приложения. Теперь же, с выходом 14.04, опытным путем было обнаружено, что пакет php5 стал предоставлять версию интерпретатора 5.5, на которой vBulletin уже не просто сыпит deprecation warning'ами, но и вовсе отказывается запускаться. За пару часов гугления и продирания через "вредные советы" вроде замены trusty на precise в sources.list, и преобретения очередной пары седых прядей, был обнаружен более-менее подходящий на мой непрофессиональный взгляд инструмент phpbrew (). Не с первого раза, конечно, но все же удалось кое-как собрать версию 5.3, запустив при этом vBulletin. Тем не менее, по хорошему, всех проблем это не решило. Раз уж есть подобный инструмент, то, вероятно, было бы интереснее для vBulletin иметь версию 5.2, которая не раздувает error.log и вообще примерно соответствует времени написания софта. Однако, phpbrew наотрез отказался предоставить install скрипт для столь древнего интерпретатора, а попытки сделать это при помощи костылей () не увенчались успехами, установка валится на этапе компиляции. Возможно у сообщества уже есть какие-то конкретные решения для данной проблемы, либо имеются более продвинутые инструменты, нежели phpbrew? Сам я со стеком php/apache/mysql дел никаких не имею и мой опыт в данной сфере ограничен необходимостью раскатывания раз в пару лет пяти-шести легаси инстансов vBulletin версии 3.8. Поэтому с промышленными решениями в данной области не знаком, буду благодарен, если ткнут пальцем куда копать. Сейчас есть желание все эти legacy-инстансы вынести на отдельную машину, рассовав по контейнерам lxc, поэтому очень хочется сделать контейнер-образец с 5.2, настроив его один раз и забыв о php-стеке ещё лет на пять. Пока что получился лишь контейнер с 5.3, безумно раздувающий error.log за счет deprecated функций. Предложения обновить vBulletin не рассматриваю, так как все инстансы существуют порядка десяти лет, накопив за это время приличное количество разработанных под конкретный проект кривых "продуктов", которые обновлять до более поздней версии попросту некому, да и, насколько мне не изменяет память, лицензия vBulletin не позволяет использовать более свежие версии софта не продляя обновления. Могу ошибаться, но вроде до смены владельцев бренда именно так и было. Предложения собрать 5.2 из сурсов видимо тоже не рассматриваю, так как боюсь, что из-за недостатка квалификации в данном стеке это решение будет чревато большими проблемами, чем раздутый error.log. В идеале, конечно, узнать про какой-нибудь магический ppa репозиторий с 5.2, либо инструмент, подобный phpbrew, либо совет, как оный phpbrew приготовить, заставив собрать 5.2. Буду благодарен за любые идеи, день самостоятельного поиска решения приличных результатов не дал. Вся надежда на сообщество. Обновление: Нормального решения найти не удалось, но решение возможно при помощи костыля, исправляющее исходники форума - Проблема vBulletin версии 3.8.4 некорректно работает с интерпретатором php 5.3 и выше. В error_log попадает бесчетное количество бессмысленных deprecated warning'ов, что заставляет его моментально разрастаться. Решение Данный скрипт позволяет в автоматическом режиме исправить некоторые проблемы vBulletin 3.8.4, проанализировав все входящие в дистрибутив php файлы и сделав автозамену устранить их. Пока что поддерживается только решение Assigning the return value of new by reference is deprecated. Поиск ведется как в php файлах проекта, так и в коде модулей в mysql из таблицы plugin. Настройки подключения скрипт подхватит автоматически, если встретит валидный config.php от vBulletin. В случае, если такого конфига найдено не было, изменения в базе данных производиться не будут. Использование скрипта осуществляется исключительно на свой страх и риск. Решение тестировалось на одном проекте, но нет никаких гарантий, что скрипт не поломает другой проект при бездумном использовании. Установка Для работы скрипта необходим интерпретатор python версии 2.7. Вероятно он так же будет работать на третьей ветке, либо при минимальных правках, однако работа в третьей ветке не тестировалась. Для ubuntu потребуется пакет python-dev, а так же пакет с хидерами mysqlclient: libmysqlclient-dev в ubuntu или libmariadbclient в ArchLinux. Перед началом работы потребуется установить пакеты с зависимостями. Сделать это проще простого, поможет команда pip install -r requirements.txt Сделать это можно либо под рутом, установив пакеты в основную систему (Не очень хорошее решение), либо используя . В целом процесс развертывания и использования скрипта выглядит примерно следующим образом: Code:

если коротко, саппорт (т.е. данный форум) крутится на пхп 5.3 и при небольших правках файлов, будет крутиться и на пхп 5.4, 5.5 на локалке (винда) установлен движок версии 3.8.7 + апач 2.4 + пхп 5.4 + mysql 5.5 - в логах ошибок пусто =) хаки, которые работали на 3.6-3.7, работают без проблем и дальше, ну разьве что, устаревшие функции подправить

@Core dumped, а какая версия запускалась под 5.5? Вот буквально на днях, запускали vb 3.8.7 на Code: