Webtatic repo

[aleksejsmir]

Как думаете, достоин ли доверия репозиторий Webtatic? Есть кое-какие сомнения у моих коллег относительно целесообразности обновлять из этого репа, скажем, from php5.4 - to php 5.6 на седьмом RHEL или центосе. Между тем это очень легко и обновление проходит без проблем:

Код: Выделить всё

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
yum install yum-plugin-replace
yum replace php-common --replace-with=php56w-common

Что известно и что думаете о репозитории Энди Томпсон ?

[Bizdelnick]

А что тут думать? Репозиторий поддерживается одним человеком, со всеми вытекающими. Для личного пользования, на свой страх и риск, сгодится, для критичных применений — нет. В крайнем случае стянуть оттуда нужные srpm, пересобрать и поддерживать своими силами, чтобы внезапная смерть репозитория или отсутствие какого-нибудь обновления с исправлением уязвимости не стало проблемой.

[aleksejsmir]

Ок. Альтератива, any ideas?
В репозиториях Centos/RHEL на сегодня отсутствуют php5.5 и 5.6, возможности обновиться, таким образом, нет. Видимо, считаются сырыми еще. Между тем, php 5.4 уже крайне нежелательно использовать ввиду имеющихся прорех безопасности, об этом пишет, насколько помню, даже Реми (главный по тарелочкам, т.е. по пыху, в федорке) в своем блоге. К слову, только что прошла атака на joomla-сайты, использующая уязвимость zero-day, и php5.4 играла здесь, вероятно, не последнюю роль.
Остается либо обновление из webstatic, либо из репов того же Реми. Но у него тоже личный репозиторий, поддерживаемый одним человеком. Что же делать?

[Bizdelnick]

Альтератива

Я же написал: пересобирать, выкладывать в своём репозитории. Причём за основу я бы таки взял пакеты из Федоры (там сейчас 5.6.16).

только что прошла атака на joomla-сайты, использующая уязвимость zero-day, и php5.4 играла здесь, вероятно, не последнюю роль.

https://developer.joomla.org/security-centr...nerability.html
Причём бы здесь версия php?

[aleksejsmir]

Причём бы здесь версия php?

Взгляните, скажем, здесь, это более подробный анализ случившегося. Я имел в виду эту багу пыха.

Though, the session_decode uses the same principles and wasn’t fixed. In september 2015, the exploit CVE-2015-6835 was filled. This made it possible to inject some data into the session array by carefully crafting your decoding string.

---------
This bug is already fixed and released in PHP 5.4.45, PHP 5.5.29, PHP 5.6.13, in all supported Ubuntu, Debian and RedHat channels. And it was all released by end september. This exploit is critical for the Joomla! exploit to work, so everybody that installs the security releases of PHP was already save! High five for all those awesome people using automatic updaters!

Advice: Make sure you always use the latest version of your software

P.S. Кстати... "This bug is already fixed and released in PHP 5.4.45"... но я не получал обновлений для своего RHEL7.1, их не было! почему - я не знаю. Создавать же свой репозиторий... хм.

Код: Выделить всё

$ php -v
PHP 5.4.16 (cli) (built: Jun 10 2015 04:34:17)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[Bizdelnick]

Ну значит в редхате решили, что php — это неэнтерпрайзно и вообще вчерашний день, и забили на его поддержку. Если всё настолько плохо, может вообще посмотреть в сторону других дистрибутивов? Я-то поначалу подумал, что вам просто каких-то фич последних версий php не хватает.

[BigBrother]

Ок. Альтератива, any ideas?

Собери из исходников.

[Vascom]

Для PHP 5.5, 5.6 и даже 7.0 есть репозитории remi http://rpms.famillecollet.com/enterprise/7/
Они конечно тоже сторонние, но всё же сам remi человек надёжный, маинтейнер пакетов в федоре и EPEL.

[Bizdelnick]

remi человек надёжный

Он, как и все люди, смертен, причём внезапно смертен...

[Vascom]

Не спорю, просто альтернатива.
Если уж человек вообще берётся использовать сторонние репозитории, то должен осознавать риски. На то они и не основные репозитории.

[aleksejsmir]

remi человек надёжный

Он, как и все люди, смертен, причём внезапно смертен...

Remi человек уважаемый и авторитетный, спору нет. Я в курсе про его репы. В том и вопрос, что всего две альтернативы - репозитории Webtatic и Remi, а в оф. репах те же самые версии пыха, которые сам Реми вполне обоснованно называет уязвимыми, см. по ссылке. Технических проблем поставить php из неофициального источника нет, вопросы вызывает лишь позиция RedHat, которая медлит исправить данное плачевное положение дел.

Vascom, я уже предвижу дальнейшее развитие разговора с вашим участием, почему предупреждаю сразу: излюбленный ваш аргумент мутишь воду, причем почему-то "на ты", хотя пиво я с тобой никогда не пил, представляется мне весьма странной аргументацией для человека, в силу каких-то непонятных и ошибочных причин считающего себя инженером.

[Vascom]

Vascom, я уже предвижу дальнейшее развитие разговора с вашим участием, почему предупреждаю сразу: излюбленный ваш аргумент мутишь воду, причем почему-то "на ты", хотя пиво я с тобой никогда не пил, представляется мне весьма странной аргументацией для человека, в силу каких-то непонятных и ошибочных причин считающего себя инженером.

Вы меня с кем-то спутали. Ни в чём подобном ни когда замечен не был. По приведённой ссылке всё очевидно.

Кстати, не обязательно с кем-то пить, чтобы общаться на "ты". Тем более в интернете, где возраст не видно. Тем более на таких ресурсах, где общаются добропорядочные единомышленники.

Если я когда-то обратился к вам на "ты", то прошу меня извинить. И прошу более не оскорблять меня безосновательно!

[aleksejsmir]

По приведённой ссылке всё очевидно.

разумеется.
И по приведенной выше ссылке, и по приведенной ниже ссылке -
Fedora 22
все очевидно.
Очевидно для вас, но куда менее очевидно для пользователей Fedora... в том и смехотворность ситуации. Именно потому я и ушел с федорки; из-за невероятно снобистской, непрофессиональной позиции мейнтейнеров Fedora, во всяком случае - русскоязычных мейнтейнеров. Впечатление невероятно раздутых самолюбий вкупе с невероятно низким уровнем профессиональной компетенции; поверьте, мне есть с чем сравнивать, и это моя констатация, а не оскорбление.

Но это так, к слову. Vascom, коли уж вы приняли участие в обсуждении; скажите, какова, на ваш взгляд, причина того, что в оф. репах RHEL/Centos до сих пор (пару дней назад еще была, проверял) присутствует только старая версия php, которая, по словам того же REmi (ссылка на его блог чуть выше), обозначена как содержащая уязвимость? Я уже приводил линк на описание и технический анализ только что прогремевшей для любителей Joomla уязвимости первого дня; если дать себе труд прочесть - несложно убедиться, что уязвимая версия php сыграла в произошедшем непоследнюю роль. На мой взгляд, весьма странная позиция, которой непросто найти аналог: любой разработчик сочтет своим долгом спасти своих пользователей от найденной уязвимости так быстро, как только сможет, в противном случае и сам он, и его продукт окажутся в немалой степени, эээ... дискредитированными.
Можете ответить, Vascom, по возможности, без этих привычных для вас "мутишь воду", подкрути ченить, вдруг заработает" и тому подобного? Вы сильно заблуждаетесь, полагая, что подобный стиль общения привычен для технарей в той же степени, сколь для вас. Задан прямой вопрос, могу я призвать всех участников дискуссии к столь же прямым ответам?

[Vascom]

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

Простой ответ - не знаю.
Развёрнутый ответ - поскольку я этим не пользуюсь, то даже не могу предположить политику RedHat в отношении обновлений PHP. По хорошему надо найти багрепорт в багзилле с описанием этой уязвимости (если нет такого - создать). Там сотрудники компании ответят с большой долей вероятности. А может и выпустят обновление с исправлением.

P.S. Ещё раз прошу не переходить на личности и не оскорблять. Ну что я вам такого плохого ответил в этой конкретной теме?

[aleksejsmir]

Vascom, я всего лишь позволил себе процитировать ваши ответы. Если даже вам собственные цитаты сейчас видятся "оскорбительными" - все действительно очевидно. ))
Ссылку на багу php я приводил (не на багзиллу, правда, а на php.net). Вопрос остается открытым; кто-нибудь компетентен в теме относительно политики REdhat в контексте пыха? Расскажите, интересно же. Попробовать разве спросить у Remi.... ну, если никто не знает, попробую.
Vascom, неужели вам не у кого поинтересоваться? ну же, не ленитесь. Подвигайте чуть-чуть не буду говорить чем, вы ведь вроде как ближе к красной шапке чем любой из нас. И вопрос, согласитесь, достаточно серьезен.

[Vascom]

Вы их не цитируете, а вырываете из контекста. Мои слова не оскорбительны ни для меня, ни для тех, кому предназначались, поскольку не ставят целью кого-то оскорбить.
Да, ссылку на баг php я видел, но не смог пока найти упоминания об этом в багзилле RedHat.

Спросить у Remi - отличная идея. Например сборки php для CentOS делает именно он:
* Ср июн 10 2015 Remi Collet <rcollet@redhat.com> - 5.4.16-36
- fix more functions accept paths with NUL character #1213407
* Пт июн 05 2015 Remi Collet <rcollet@redhat.com> - 5.4.16-35
...
Так же, судя по его адресу электронной почты, remi является сотрудником RedHat.

Мне не у кого поинтересоваться. Я не сотрудник RedHat. И вопрос для меня не серьёзен, поскольку в Fedora с этим проблем нет. Я на столько же ближе к шапке по сравнению с вами, как автослесарь "из гаражей" ближе к Mercedes и концерну Daimler.

P.S. Уже можно на "ты" или обязательно сперва совместное употребление слабоалкогольных напитков?

[Bizdelnick]

ссылку на баг php я видел, но не смог пока найти упоминания об этом в багзилле RedHat.

Естественно. Если соответствующий баг там и есть, то, как и все баги, связанные с безопасностью, скрыт до тех пор, пока не будет исправлен. Да и с учётом того, что CVE опубликовали ещё в сентябре, все заинтересованные должны быть в курсе, даже если багрепорта не было.

[aleksejsmir]

Если соответствующий баг там и есть, то, как и все баги, связанные с безопасностью, скрыт до тех пор, пока не будет исправлен. Да и с учётом того, что CVE опубликовали ещё в сентябре, все заинтересованные должны быть в курсе, даже если багрепорта не было.

Really! Вот что-что, а присланную мейнтейнеру пакета php ссылку на багу php трехмесячной давности я бы реально посчитал оскорблением, на месте мейнтейнера.

Bizdelnick, вы думаете? такое действительно принято; но в несколько иных, вроде бы, ситуациях... какой смысл скрывать багу на багзилле, когда бага на php.net всем давно доступна.

Я объясню... неделю назад аккурат всю ночь просидел, копаясь в файлах и конфигах, пытаясь понять, почему, несмотря на все принятые меры, зараза все-таки просачивается на сайт... думал до этого, что достаточно адекватно настроил в контексте безопасности этот веб-сервер. Selinux, безопасные permissions, open_basedir, disable_functions, отсутствие левых расширений на сайте... хваленый RHEL 7.1.... не секрет, что многие админы дебиана, скажем, даже не подозревают, что selinux есть и у них, только отключен по-дефолту; но нет же, потому и предпочел RHEL/Centos, что допиленный в редхате selinux отлично работает почти из коробки, всего только chcon сделаешь, ну и setsebool для почты, и привет, все пашет. Так и не понял, в чем прикол, откатился из бэкапа и лег спать. А как проснулся, уже вовсю трубили про "уязвимость первого дня"... погуглил на тему, и стало мне совсем нехорошо. Тут сообщения посыпались от пользователей, не только на форум, но и на почту, взломы и взломы... сравнили шеллы и логи, погуглили инфу на тему, и завертелись у меня на языке непарламентские выражения, и не в адрес Joomla team.

Джумлаводы действительно выпустили security-фикс в аварийном порядке; прикрыв тем самым, помимо своих, еще и неисправленную, читай по*еренную его преосвященством RedHat багу... молодцы. И коммерческий ведь дистриб, я RHEL имею в виду!.. Невольно приходит в голову смелое предположение, что стиль работы мейнтейнеров федорки, о котором уже позволил себе высказать субъективное мнение чуть выше... всецело в русле логики работы RedHat.

[aleksejsmir]

И вопрос для меня не серьёзен, поскольку в Fedora с этим проблем нет.

Замечательный ответ, 5 баллов... а вот для меня вопрос серьезен, и не только для меня, думаю... кстати, уж простите, что приходится транслировать здесь joomla-новости, но они имеют, как мне кажется, непосредственное отношение к нашему разговору. Только что Joomla team подтвердила, что причиной многочисленных взломов сайтов действительно является уязвимый php, исправленный еще в сентябре, оригинал заявления - те, кому не все равно, не лениво и не пофиг, могут прочесть на joomla.org:

The Joomla Security Strike team has been following up on the critical security vulnerability patched last week. Since the recent update it has become clear that the root cause is a bug in PHP itself. This was fixed by PHP in September of 2015 with the releases of PHP 5.4.45, 5.5.29, 5.6.13 (Note that this is fixed in all versions of PHP 7 and has been back-ported in some specific Linux LTS versions of PHP 5.3). This fixes the bug across all supported PHP versions.

[Vascom]

Я так ответил вот на этот выпад

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

Для вас вопрос серьёзен - кто же против, я же пытаюсь вам помочь. Но вот лениться или нет уж позвольте мне самому решать, как и оценивать серьёзность вопроса лично для меня. Вы же мне не платите за техподдержку.
Кстати, если у вас RHEL, то и платная техподдержка есть. Вы к ней обращались? Интересно было бы услышать их ответ.

[aleksejsmir]

Вы же мне не платите за техподдержку.
Кстати, если у вас RHEL, то и платная техподдержка есть

Очередной нелогичный вывод, выдающий полное незнакомство с предметом. Второе вовсе не априори следует из первого, Vascom.
У меня действительно лицензионный RHEL, и действительно никакой платной техподдержки.
Сами догадаетесь, в какой ситуации такое возможно, или намекнуть на правильный ответ? впрочем, это не относится к тебе нашего разговора.
P.S. Я уже почти готов заплатить вам, только бы вы перестали здесь флеймить. Не могли бы вы удостоить своим внимание какую-то иную ветку форума? Перечитайте свои реплики; кроме "не знаю", вы еще ничего не сказали по делу.

[Vascom]

Не я тут начал флеймить, а вы.
Мой первый ответ в этой теме был плох? Webtatic repo

Мои "не знаю" относятся лишь к вашим прямым вопросам. Чем этот ответ вас не устроил? Может вы и правда ожидали, что я сотрудник Red Hat и всё знаю?

Ну раз помощь не нужна и вы только и можете, что собачиться - ваше право. Можете мне заплатить, если хотите.

Обещаю в дальнейшем игнорировать все ваши нападки и отвечать по делу.

[aleksejsmir]

Ну раз помощь не нужна и вы только и можете, что собачиться - ваше право. Можете мне заплатить, если хотите.

Ну и форумы - не платная техподдержка, чтобы вы могли от меня что-то требовать.

Вы очень навязчивы в предложении своей "помощи", Vascom. И что-то очень уж часто заводите разговор о деньгах. Не переоцениваете ли вы стоимость своей "помощи"? Мне придется напомнить, что однажды мы уже достигли с вами определенного соглашения на этот счет:

Если лично вам не нравится - вам не буду помогать. Но другие от этого страдать не должны.

Мне придется напомнить вам ваше обещание. Еще раз - мне не нужна ни ваша "помощь", ни ваша пустопорожняя болтовня. Никто не пострадает, по крайней мере в этом топике (здесь пока только я и модератор), от отсутствия очередного тролля, пиарящего свое уязвленное самолюбие. Еще раз; нужна мне помощь конкретно от вас либо не нужна - решать мне. Это привилегия попросившего о помощи, и не только на форумах. Решение мое вам известно. Думаю, логично? "Помощь" ваша чересчут уж навязчива, и ничего, кроме самопиара, в себе не несет. Я говорю техническим языком и о проблемах безопасности, касающихся, как минимум, двух популярных серверных дистрибутивов, вы же вчистую краснобайствуете, для вас все это "несерьезно", и тему, как сами признались, вы "не знаете". Ну так и замечательно, коли не знаете - говорить не о чем, до свиданья.

Я вынужден попросить помощи у администрации форума, ну сколько можно слушать болтовню технически неграмотного человека. Vascom хорошо известен среди моих коллег и на форумах рунета, это человек, находящий время пиариться одновременно на всех веб-ресурсах, и умудряющийся везде отделываться общими фразами, не несущими в себе ни малейшей технической информации... отлично, бог в помощь... но это никоим образом не способствует решению проблемы. Прошу представителя администрации форума определить свою позицию: с учетом вышесказанного, и если наши взгляды на троллинг расходятся - говорить не о чем, если же коррелируют - прошу избавить хотя бы мои топики от очередного полуграмотного тролля... мне, в общем, и на своем форуме (ссылка выше) болтунов хватает. Свобода дискуссии не включает в себя возможность забалтывать обсуждение, как известно... послушайте, ну если есть заявление о том, что квалификация добровольного помощничка не внушает доверия, а других заявлений на данный момент нет - о чем вообще может быть разговор? любой мало-мальски дельный специалист своего дела уже бы испарился, ценя время, а этот бедолага все еще здесь топчется и что-то эдакое назойливо зудит над ухом.

[Bizdelnick]

[offtopic]

здесь пока только я и модератор

На этот раздел мои модераторские полномочия не распространяются, если что — под каждым сообщением есть соответствующая кнопка.[offtopic]

[aleksejsmir]

[offtopic]

здесь пока только я и модератор

На этот раздел мои модераторские полномочия не распространяются, если что — под каждым сообщением есть соответствующая кнопка.[offtopic]

ок, спс, отправил:

Моя просьба подробно изложена в последнем моем сообщении; in two words: однажды мне удалось добиться от странного вашего форумчанина обещания оставить хотя бы мои сообщения без своего троллинга; но назойливая болтовня этого псевдоспециалиста по прежнему присутствует. Хотелось бы грамотного обсуждения, а не пустой псевдотехнической болтовни полуграмотного краснобая, прошу помощи. Я понимаю, что есть свобода обсуждения, но существует также и такое понятие как профессиональный разговор, в который слабо вписываются потуги самопиара и болтовни о себе любимом.

[aleksejsmir]

Буду благодарен, если у кого мысли появятся по существу вопроса.. пробую новый VDS на базе KVM от Спейсвеба, 1 месяц бесплатно... если кто не знал и захочет присоединиться - welcome, опубликовал инфу здесь. А вопрос все тот же; нету в репех центоса актуального пыха, а есть старый... новый можно получить только из неофициальных источников - из репов Remi или Webtatic. И вот этот последний, название которого вынесено в заголовок темы - на этом самом новом VDS от Спейсвеба валится у меня напрочь на коннекте (возможно) к БД. Бэктрэйс публикую, если кто-нить решится на свежую голову подумать и покопать (для этого надо всего только зарегиться на таймвебе и попросить виртуалку, за пять минут будет готова), или просто на основе сказанного... короче вот, информация к размышлению. На Webtatic зарепортил, только сомнения у меня немалые, что будут там в этом разбираться:

Код: Выделить всё

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7ffff7feb840 (LWP 30343)]
0x00007ffff6ad06cd in __libc_send (fd=18, buf=0x555555cae500, n=22, flags=64) at ../sysdeps/unix/sysv/linux/x86_64/send.c:27
27          return INLINE_SYSCALL (sendto, 6, fd, buf, n, flags, NULL, (size_t) 0);
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 elfutils-libelf-0.163-3.el7.x86_64 elfutils-libs-0.163-3.el7.x86_64 freetype-2.4.11-11.el7.x86_64 gmp-6.0.0-12.el7_1
.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 libX11-1.6.3-2.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXpm-3.5.11-3.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 libcurl-7.29.0-25.el7.centos.x86_64 libgcc-4.8.5-4.el7.x86_64 libgcrypt-1.5.3-12.el7_1.1.x86_64 libgpg-error-1.12-3.el7.x86_64 libidn-1.28-4.el7.x86_64 libjpeg-turbo-1.2.90-5.el7.x86_64 libpng-1.5.13-7.el7_2.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 libtidy-0.99.0-31.20091203.el7.x86_64 libuuid-2.23.2-26.el7_2.2.x86_64 libxcb-1.11-4.el7.x86_64 libxml2-2.9.1-6.el7_2.2.x86_64 libxslt-1.1.28-5.el7.x86_64 nspr-4.11.0-1.el7_2.x86_64 nss-3.21.0-9.el7_2.x86_64 nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 nss-util-3.21.0-2.2.el7_2.x86_64 openldap-2.4.40-9.el7_2.x86_64 openssl-libs-1.0.1e-51.el7_2.4.x86_64 php56w-5.6.20-1.w7.x86_64 php56w-bcmath-5.6.20-1.w7.x86_64 php56w-common-5.6.20-1.w7.x86_64 php56w-gd-5.6.20-1.w7.x86_64 php56w-mbstring-5.6.20-1.w7.x86_64 php56w-mysqlnd-5.6.20-1.w7.x86_64 php56w-opcache-5.6.20-1.w7.x86_64 php56w-pdo-5.6.20-1.w7.x86_64 php56w-process-5.6.20-1.w7.x86_64 php56w-tidy-5.6.20-1.w7.x86_64 php56w-xml-5.6.20-1.w7.x86_64 sqlite-3.7.17-8.el7.x86_64 t1lib-5.1.2-14.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64
(gdb) bt
#0  0x00007ffff6ad06cd in __libc_send (fd=18, buf=0x555555cae500, n=22, flags=64) at ../sysdeps/unix/sysv/linux/x86_64/send.c:27
#1  0x00007fffea4b6ecf in php_sockop_write () from /etc/httpd/modules/libphp5.so
#2  0x00007fffea4a9b7e in _php_stream_write_buffer () from /etc/httpd/modules/libphp5.so
#3  0x00007fffdc3943de in php_mysqlnd_net_send_ex_pub () from /usr/lib64/php/modules/mysqlnd.so
#4  0x00007fffdc38d130 in php_mysqlnd_cmd_write () from /usr/lib64/php/modules/mysqlnd.so
#5  0x00007fffdc3844e0 in php_mysqlnd_conn_data_simple_command_send_request_pub () from /usr/lib64/php/modules/mysqlnd.so
#6  0x00007fffdc3823ce in php_mysqlnd_conn_data_simple_command_pub () from /usr/lib64/php/modules/mysqlnd.so
#7  0x00007fffdc38711b in php_mysqlnd_conn_data_send_query_pub () from /usr/lib64/php/modules/mysqlnd.so
#8  0x00007fffdc386f73 in php_mysqlnd_conn_data_query_pub () from /usr/lib64/php/modules/mysqlnd.so
#9  0x00007fffdc383fb8 in php_mysqlnd_conn_data_set_charset_pub () from /usr/lib64/php/modules/mysqlnd.so
#10 0x00007fffdbf5b5e5 in zif_mysqli_set_charset () from /usr/lib64/php/modules/mysqlnd_mysqli.so
#11 0x00007fffea4e5c6b in dtrace_execute_internal () from /etc/httpd/modules/libphp5.so
#12 0x00007fffea59f154 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#13 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#14 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#15 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#16 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#17 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#18 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#19 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#20 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#21 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#22 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#23 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#24 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#25 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#26 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#27 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#28 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#29 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#30 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#31 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#32 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#33 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#34 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#35 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#36 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so
#37 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so
#38 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so
#39 0x00007fffea4f886b in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#40 0x00007fffea493d62 in php_execute_script () from /etc/httpd/modules/libphp5.so
#41 0x00007fffea5a0d7d in php_handler () from /etc/httpd/modules/libphp5.so
#42 0x0000555555593270 in ap_run_handler (r=r@entry=0x555555b9e690) at config.c:169
#43 0x00005555555937b9 in ap_invoke_handler (r=r@entry=0x555555b9e690) at config.c:439
#44 0x00005555555a7b3a in ap_process_async_request (r=r@entry=0x555555b9e690) at http_request.c:317
#45 0x00005555555a7e14 in ap_process_request (r=r@entry=0x555555b9e690) at http_request.c:363
#46 0x00005555555a47a2 in ap_process_http_sync_connection (c=0x555555b952e0) at http_core.c:190
#47 ap_process_http_connection (c=0x555555b952e0) at http_core.c:231
#48 0x000055555559c840 in ap_run_process_connection (c=c@entry=0x555555b952e0) at connection.c:41
#49 0x000055555559cc28 in ap_process_connection (c=c@entry=0x555555b952e0, csd=<optimized out>) at connection.c:202
#50 0x00007fffeda1980f in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:707
#51 0x00007fffeda19a55 in make_child (s=0x555555800320, slot=slot@entry=0) at prefork.c:810
#52 0x00007fffeda19ab6 in startup_children (number_to_start=5) at prefork.c:828
#53 0x00007fffeda1a7c0 in prefork_run (_pconf=<optimized out>, plog=0x555555804358, s=0x555555800320) at prefork.c:986
#54 0x00005555555795ae in ap_run_mpm (pconf=pconf@entry=0x5555557d7138, plog=0x555555804358, s=0x555555800320) at mpm_common.c:96
#55 0x0000555555572b36 in main (argc=2, argv=0x7fffffffe0d8) at main.c:777
(gdb) q
A debugging session is active.

[Bizdelnick]

Вы покажите, что за команду запускали-то, а если там был какой-то скрипт — то этот скрипт (в минимизированном для воспроизведения ошибки виде).
И Вы уверены, что дело в сборке php, а не в том, например, что файрвол режектит пакеты?

[aleksejsmir]

И Вы уверены, что дело в сборке php, а не в том, например, что файрвол режектит пакеты?

да, я уверен в том, что firewalld здесь ни при чем. Что касается неофициального php - не знаю, в этом и заключается вопрос.

Постараюсь описать последовательность шагов... ок, я по-быстрому опишу процесс установки репозиториев и пакетов, это будет вполне точный репродьюс, т.к. делал подобное не единожды в контексте RHEL 7.1 и 7.2. Последовательность шагов и синтаксис, возможно, незначительно менялись, сессию не логгировал, пишу по памяти. Но суть неизменна. Версии пакетов - соответственно, те, которые находятся на данный момент в указанных репах; VDS же я получил с уже предустановленным Centos 7.1.

1. разумеется, обновление:

Код: Выделить всё

sudo yum update

далее апач:

Код: Выделить всё

sudo yum install httpd
sudo systemctl enable httpd.service
sudo systemctl start httpd.service

и mariadb:

Код: Выделить всё

sudo yum install mariadb-server
sudo systemctl enable mariadb

рестарт mariadb, запускаем постинсталляционный скрипт и удаляем демки, ставим пароль:

Код: Выделить всё

sudo /usr/bin/mysql_secure_installation

в /etc/my.cnf по привычке прописал utf-8 по-дефолту:

Код: Выделить всё

[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’
character-set-server = utf8
collation-server = utf8_unicode_ci
[client]
default-character-set = utf8

подключаем epel и webtatic:

Код: Выделить всё

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

после чего уже можно ставить новый php 5.6.20 из webtatic и phpmyadmin из епеля. К слову, последний установился и создал необходимые таблицы в своих базах без малейших проблем. Сервер предназначался для сугубо тестов, это не продакшн, поэтому конфига php практически не касался, разве что включил short_open_tag и сделал минимально необходимые настройки в phpmyadmin:

Код: Выделить всё

$cfg['Servers'][$i]['auth_type'] = ‘http‘;

и прописал свой ip для phpmyadmin.


Далее, распаковал файлы cms в по-умолчанию каталог html (виртуалхосты не делал), подарил (chown) каталог рекурсивно апачу (контекст в данном случае не нужен, т.к. selinux был по-умолчанию отключен), зашел через web (разумеется, предварительно сделав # firewall-cmd --permanent --zone=public --add-port=80/tcp ) и на этапе привязки базы данных к cms наткнулся на странную проблему, дебаг которой уже приводил. Вроде бы все.... буду благодарен за замечания и дельную критику в контексте описанного step-by-step; сертифицированным специалистом по RedHat я не являюсь, но проделывал подобное не единожды... впрочем, варианты всегда возможны и только приветствуются.

[Bizdelnick]

Вроде бы все

Не всё. Вы не ответили на заданный мной вопрос. Что именно Вы запускали под gdb? От чего трассировка-то?

[aleksejsmir]

Что именно Вы запускали под gdb? От чего трассировка-то?

апач
http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html