Собственно, недавно пришлось столкнуться с такой напастью, отсюда возник вопрос к профессионалам: А как вы, собственно, деплоите 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 (https://github.com/phpbrew/phpbrew). Не с первого раза, конечно, но все же удалось кое-как собрать версию 5.3, запустив при этом vBulletin. Тем не менее, по хорошему, всех проблем это не решило.

Раз уж есть подобный инструмент, то, вероятно, было бы интереснее для vBulletin иметь версию 5.2, которая не раздувает error.log и вообще примерно соответствует времени написания софта. Однако, phpbrew наотрез отказался предоставить install скрипт для столь древнего интерпретатора, а попытки сделать это при помощи костылей (https://github.com/phpbrew/phpbrew/issues/429) не увенчались успехами, установка валится на этапе компиляции.

Возможно у сообщества уже есть какие-то конкретные решения для данной проблемы, либо имеются более продвинутые инструменты, нежели 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.
Буду благодарен за любые идеи, день самостоятельного поиска решения приличных результатов не дал. Вся надежда на сообщество.

Обновление:
Нормального решения найти не удалось, но решение возможно при помощи костыля, исправляющее исходники форума - проект на github
readme костыля

Проблема
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

Сделать это можно либо под рутом, установив пакеты в основную систему (Не очень хорошее решение), либо используя virtualenv.

В целом процесс развертывания и использования скрипта выглядит примерно следующим образом:

ubuntu@domain:~$ cd /tmp
ubuntu@domain:/tmp$ git clone https://github.com/dumpedc/vbfixer.git
ubuntu@domain:/tmp$ cd vbfixer
ubuntu@domain:/tmp/vbfixer$ virtualenv env
ubuntu@domain:/tmp/vbfixer$ source env/bin/activate
(env)ubuntu@domain:/tmp/vbfixer$ pip install -r requirements.txt
(env)ubuntu@domain:/tmp/vbfixer$ python vbfixer.py /sites/domain.tld/public/

Где /sites/domain.tld/public - путь до вашей установки vBulletin.

Использование

Usage: python vbfixer.py [OPTIONS] PATH

Options:
  -v                        Расширенный вывод
  -c TEXT                   Кодировка файлов. Если не указана, будет
                            определена через libmagic
  -s                        "Тихий" режим. Все замены будут произведены
                            автоматически. В каталогах будут созданы patch-
                            файлы с аналогичными именами
  -i [assign_by_reference]  Включает только конкретные проверки из заданного
                            списка
  --no-mysql                Не проверять модули в базе данных
  --help                    Show this message and exit.

По умолчанию скрипт запускается в интерактивном режиме, запрашивая подтверждение на каждое изменение.

Ключ -s включает "тихий" режим, производящий автоматические замены, но при этом оставляя рядом unix patch-файлы с описанием проделанных изменений, что позволяет быстро откатить нежелательные.

Ключ --no-mysql позволяет запустить скрипт без проверки модулей из таблицы plugin в базе данных, даже в том случае, если будет обнаружен валидный config.php.
Если запускаете с изменением модулей, то не забудьте: после изменений в таблице plugin надо перестраивать datastore
штатно это делается совершенно банально: пересохранением любого модуля в админке

PATH может быть как конкретным файлом (Например python vbfixer.py /tmp/vbulletin/includes/init.php), так и каталогом (Например python vbfixer.py /tmp/vbulletin).

В случае каталога скрипт будет осуществлять рекурсивный поиск во всех файлах с расширением .php внутри каталога.

Более корректного решения в 2015 году нет, либо найти его общими силами не удалось.

если коротко, саппорт (т.е. данный форум) крутится на пхп 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 на

PHP 5.6.10 (cli) (built: Jun 11 2015 08:33:51)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

В чем проблема то? В варнингах - так это фиксится весьма несложно.

Просто держать на сервере окаменелость мамонта ради чего?

Originally Posted by kerk

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

Благодарю за оперативный ответ!
А как боретесь с deprecation warning'ами? Например самый частый грешок из-за особенностей реализации ООП аж в php4, с которой vBulletin тянет совместимость, это "Assigning the return value of new by reference is deprecated". Таких штуковин на один запрос падает порядка 3-4 в лог, из-за чего он раздувается моментально до невероятных размеров. Есть какие-то директивы в php.ini, позволяющие отключить данное поведение в 5.3? В свое время не нашел решения.
Про совместимость между третьей линейкой знаю, даже сталкивался напрямую в свое время. На данный момент все инстансы работают на 3.8.4.

Originally Posted by Smalesh

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

PHP 5.6.10 (cli) (built: Jun 11 2015 08:33:51)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

В чем проблема то? В варнингах - так это фиксится весьма несложно.

Просто держать на сервере окаменелость мамонта ради чего?

Запускалась версия 3.8.4. Конкретно самые очевидные проблемы были с драйвером mysql из-за deprecated mysql_* функций. Иными словами ни одна страница не открывалась из-за "ошибки базы данных". Ну и ещё с десяток всяких deprecated, против 3-4 на php 5.3. Глубже не копал, но не факт, что это все проблемы.
Что касается окаменелости мамонта на сервере, то в первом посте я указал, что собираю контейнеры lxc под каждый инстанс. На сервере интерпретатор php вообще не установлен, так как в нем нет надобности. А уж что там будет внутри контейнера - не столь важно, тем более, что сам vBulletin - софт 2007 года, как и php 5.2. Вполне логично было бы держать их вместе.

Originally Posted by Core dumped

Assigning the return value of new by reference is deprecated

у нас это даже в правила вынесено, на столько часто этот вопрос здесь задавался
http://vbsupport.ru/forum/misc.php?d...1.2.Deprecated

Originally Posted by Core dumped

На данный момент все инстансы работают на 3.8.4.

вот и саппорт работает на 3.8.4

Originally Posted by Core dumped

проблемы были с драйвером mysql из-за deprecated mysql_* функций. Иными словами ни одна страница не открывалась из-за "ошибки базы данных".

в конфиге форума поправить mysql => mysqli

Originally Posted by kerk

у нас это даже в правила вынесено, на столько часто этот вопрос здесь задавался
http://vbsupport.ru/forum/misc.php?d...1.2.Deprecated

Благодарю за ссылку, искал немного по другой методологии, конкретно по словам "phpbrew" и "деплой". А ларчик оказывается просто открывался.
Тем не менее остались вопросы. Если речь про данное сообщение - http://vbsupport.ru/forum/showpost.p...49&postcount=9, то понятным для меня является только третий пункт. В попытках выполнить первый создан данный топик, а второе на уровне php.ini я так и не сумел в свое время разрулить.. Не подскажете нужную директиву, ну или хотя бы линк на нужный раздел php.net? Прошу прощения за невежество, просто php - совсем не моя область, здесь я откровенно плаваю.
Третий пункт, конечно, тоже возможен, но немного накладен, так как мест придется поправить изрядно, включая "продукты". А учитывая то, что grep по базе данных не ищет, а код модулей хранится именно там, то вариант выглядит совсем уж печальным.

Originally Posted by kerk

в конфиге форума поправить mysql => mysqli

Благодарю, буду знать. Хотя для 5.3 вроде работает и без этого.

тема больше подходит разделу Системное администрирование, чем "вопросам по vb 3.8"

но если вопрос стоит так

Originally Posted by Core dumped

А как вы, собственно, деплоите vBulletin в 2015 году?

то ответ примерно такой:

Originally Posted by Luvilla

тройка подгоняется под новые ПХП за вечер, неспешно, во время просмотра киношки по телеку - в рекламных паузах

если принципиально иметь пхп 5.2... то, пожалуй, ответ вот такой: http://centos-webpanel.com/features

- PHP Switcher (switch between PHP versions like: 5.2, 5.3, 5.4, 5.5)
- PHP Selector select PHP version per user or per folder (PHP 4.4, 5.2, 5.3, 5.4, 5.5, 5.6)

Originally Posted by Core dumped

версию интерпретатора 5.5, на которой vBulletin уже не просто сыпит deprecation warning'ами, но и вовсе отказывается запускаться.

да ерунда... всё запускается
небось, пишет

mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead

ну так вписать в конфиг вместо майсиквел - майсиквели, делов-то...

Originally Posted by Smalesh

на днях, запускали vb 3.8.7 на
PHP 5.6.10

у меня было всё же круче, мы ставили 3.6.0 RC на пхп 5.4 - ничего, поплыла рыбка, уговорилась

Originally Posted by Core dumped

Третий пункт, конечно, тоже возможен, но немного накладен,

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

Originally Posted by Luvilla

тема больше подходит разделу Системное администрирование, чем "вопросам по vb 3.8"

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

Originally Posted by Luvilla

если принципиально иметь пхп 5.2... то, пожалуй, ответ вот такой: http://centos-webpanel.com/features

А нет ли компонента switcher отдельно, подобно указанному в первом сообщении phpbrew? Потому как разбираться с деплоем сложного софта в виде панели, которой никто никогда не будет пользоваться ради одного компонента выглядит несколько "из пушки по воробьям". Да и для человека, незнакомого со стеком займет явно не один вечер. В мире python, скажем, есть утилита pyenv (https://github.com/yyuu/pyenv) позволяющая легко управлять версиями интерпретатора. В мире php, насколько я понял, все несколько сложнее, так как необходимы ещё и биндинги к apache, но сложно поверить, что сообщество за столько лет не создало сколь-нибудь приемлемого решения данной проблемы.

Originally Posted by Luvilla

да ерунда... всё запускается
небось, пишет

mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead

ну так вписать в конфиг вместо майсиквел - майсиквели, делов-то...

Да, вероятно так и было. Не знал про эту особенность конфига, теперь буду знать. Благодарю.

Originally Posted by Core dumped

Третий пункт, конечно, тоже возможен, но немного накладен,

вот честно - ерунда это
там всего-то десяток строк в ините (вобловском) и одна в класс_коре

Originally Posted by Core dumped

включая "продукты".

сколько Вы используете продуктов, в которых есть "=& new"? сто? тысячу?
другое дело, что в продуктах проблема может быть не только с =& new
там может быть и соединение с майсиквелом напрямую прописано, а если продукты совсем старые, для 3.6 - то бывает совсем тоскливо...
но, мне кажется, проще пройтись по списку продуктов, наверняка для большинства из них есть обновления, чем держаться за пхп 5.2