Архивы: ports

ZendOptimizer + php 5.2.x + mysql 5.5.x

Так случилось, что мне пришлось переносить с одного хостинга, который строил я, на другой хостинг, который тоже строю я, древнюю говноцмс HostCMS, которая закодирована Zend’ом и при этом не работает на PHP 5.3. Ни в коем случае никогда не повторяйте ошибок моих знакомых, которые выбрали ее в качестве основной платформы.

Казалось бы — нет ничего проще — ставим из портов lang/php52, он там с бэкпортами багфиксов, соответственно ничем особым не грозит, ставим devel/ZendOptimizer версии 3.3.0.a, который последний работает под amd64 на FreeBSD (но это отдельная история — для FreeBSD/i386 есть 3.3.9, но Zend тупо поленился собрать его под amd64), databases/mysql55-client — и все взлетит и заработает. Оказалось, что не тут-то было.

Апач уверенно падал (хоть php и отрабатывало и выдавало контент).

pid 50428 (httpd), uid 0: exited on signal 11 (core dumped)
pid 18434 (php), uid 0: exited on signal 11 (core dumped)

Памятуя о том, что в чудо-языке php может быть важен (причем неизвестно по какому принципу) порядок загрузки экстеншнов, я их отсортировал, но ситуация не изменилась. Более того, как видно из логов, падал не только apache, но и php cli. Воспользовавшись стандартным способом — закомментировать все экстеншны и включать по одному, я обнаружил, что виной всему все, что так или иначе зависит от mysql — pdo_mysql.so и mysql.so.

На старом хостинге использовался весь тот же набор ПО, единственным отличием была версия MySQL — на старом стоял клиент 5.0, на новом — 5.5. Ничтоже сумняшеся я задаунгрейдил mysql55-client в mysql50-client (благо mysql-server живет в отдельном jail, поэтому он не будет возражать, что в комплекте у него клиент старой версии) и пересобрал зависимости.

# portmaster -o databases/mysql50-client mysql-client-5.5.24

# portmaster php52-mysql-5.2.17_8

# portmaster php52-pdo_mysql-5.2.17_8

И, о чудо, php и apache перестали падать. Но появилась другая проблема — mysql 5.0 уверенно не хотел дружить по кодировкам с mysql-server 5.5, как я не пытался его в этом убедить при помощи /usr/local/etc/mysql/my.cnf. Ломать — так ломать, решил я, и заапгрейдил mysql-client 5.0 до 5.1 (пересобрав после этого зависимости, естественно).

# portmaster -o databases/mysql51-client mysql-client-5.0.95

# portmaster php52-mysql-5.2.17_8

# portmaster php52-pdo_mysql-5.2.17_8

И снова чудо снизошло на нас — кодировки заработали, apache и php не падает. Правда без ZendOptimizer они тоже не падают при любых версиях mysql-client.

Мораль сей басни такова — если вы уже так боитесь, что у вас украдут ваш PHP-говнокод — кодируйте чем-то приличным, которое поддерживается на всех платформах, своевременно переходите на поддержку очередной версии PHP, а не заставляйте людей жить на устаревшем дырявом ПО и иметь себе гемморой.

apache + php

В связи с очередной дырой в php, пришлось проапгрейдить 5.3.6 до 5.3.7. Естественно при этом использовался portupgrade. apache начал падать по 6-му сигналу.

Оказалось (я как бы давно подозревал, но не думал, что все настолько плохо), что апач с php падает или не падает в зависимости от порядка экстеншнов в extensions.ini.

Добрые люди подсказали скрипт, который располагает экстеншны в правильном порядке. Там же, внутри скрипта информация о том, откуда собирались идеи о «правильном порядке».

http://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh

FreeBSD + Perl 5.10=>5.12 + dependencies

# grep ^PERL_VERSION /usr/ports/Mk/bsd.perl.mk
PERL_VERSION?=  5.12.3

В связи с чем встал вопрос о пересборке всего, что зависит от перла. Но как оказалось, на моём рабочем десктопе — такового — 512 из 1139 пакетов, включая Xorg, firefox, openoffice и прочие, казалось бы никак не связанные с перлом пакеты.

Копание приводит к выводу, что все эти «непонятные» пакеты прямо или косвенно используют devel/glib20, который, в свою очередь требует Perl для выполнения в одном месте генерилки кода из темплейта.

gio/makefile.msc:       $(PERL) ..\gobject\glib-mkenums —template gioenumtypes.h.template $(gio_headers) > gioenumtypes.h
gio/makefile.msc:       $(PERL) ..\gobject\glib-mkenums —template gioenumtypes.c.template $(gio_headers) > gioenumtypes.c

После изучения этого самого glib-mkenums можно сделать вывод, что особо в нём ничего недостижимого для sed+awk+sh нет, в 90% случаев регекспы вида s/zuka/buka/.

В связи с этим возникает вопрос адекватности авторов glib, которые не смогли/не захотели реализовать это на sed+awk+sh и заставили ради трёх строчек кода тащить весь Perl.