(%

array_diff

ровно то же самое с интерсектом можно было

если конечно памяти хватит

>_<

Кто знает почему если composer запускать под обычным пользователем, то все запросы https отбрасываются, а если через root то всё норм?

Исковырял все что можно было. закачал cacert сертификаты в папке где их ищет php потом еще для надежности прописал openssl.cafile=/usr/local/share/ca-certificates/cacert.pem (который закачал из https://curl.haxx.se/docs/caextract.html) в php.ini Потом еще для надежности удалил все кэши композера из папки пользователя. Еще сделал composer self-update —update-keys - чтобы наверняка. И все-равно это говно отказывается работать.

Ни с одим пакетным менеджером я так долго еще не совокуплялся как с композером.

ну дык как там принято говорить

поюзай strace, не?

Ни с одим пакетным менеджером я так долго еще не совокуплялся как с композером.

ей, псс хочешь немножечко PECL ?

ей, псс хочешь немножечко PECL ?

Я уже наPECLся, спасибо)

Никто не встречался с подобным ?

Кинул composer в /usr/local/bin дал chmod a+x что ему еще надо ?

поставить свежий1 компосер?

баг год назад пофиксили

А если порт повыше взять, не 443?

поставить свежий1 компосер?

Поставил раза 3 уже. Заранее все почистил. Та же фигня.

Поставил раза 3 уже. Заранее все почистил. Та же фигня.

магия

У меня все через прокси.

юзер не юзает прокси при обращениях?

{"error":{"code":"EmptyArgument","message":"аžаДаИаН аИаЗ аОаБбаЗаАб‚аЕаЛбŒаНб‹б… аАб€аГбƒаМаЕаНб‚аОаВ аПбƒбб‚.","target":"ctoken"}} Шо может привести к подобному пиздецу?)

{"error":{"code":"EmptyArgument","message":"аžаДаИаН аИаЗ аОаБбаЗаАб‚аЕаЛбŒаНб‹б… аАб€аГбƒаМаЕаНб‚аОаВ аПбƒбб‚.","target":"ctoken"}} Шо может привести к подобному пиздецу?)

кодировка?

бля, во ты гений

бля, во ты гений

ну и? ищи свой mbstring/iconv/настройки кодировки в php.ini

Чо выебываться то

{"error":{"code":"EmptyArgument","message":"аžаДаИаН аИаЗ аОаБбаЗаАб‚аЕаЛбŒаНб‹б… аАб€аГбƒаМаЕаНб‚аОаВ аПбƒбб‚.","target":"ctoken"}} Шо может привести к подобному пиздецу?)

Только лишь бесподобный пиз**ц =)

юзер не юзает прокси при обращениях?

Всмысле ? Забил в /etc/environment переменные http_proxy и https_proxy и все. ЧТо-то еще нужно делать ? Ну еще для apt-get правил конфиги чтобы тоже не ругался. Остальные ПМ отлично отрабатывают.

openssl.cafile="/usr/local/etc/ssl/cert.pem" openssl.capath="/usr/local/etc/ssl"

в php.ini

и читать юзеру разреши

Пути поправь под свои

openssl.cafile="/usr/local/etc/ssl/cert.pem" openssl.capath="/usr/local/etc/ssl"

К сожалению не сработало.

ну тогда добро пожаловать

может где то там поди selinux

или apparmor

Мда... Отключаю прокси всё норм. Включаю не работает.

А, ну или прокси не так проксирует

Включаю прокси - работает под рутом, а под юзером нет. С включенным прокси npm, pip работают - а composer — нет.

Мистика.

Снесу ubuntu поставлю Debian на сервер. Эта фигня после апдейта произошла.

Збс решение

Збс решение

Других не вижу.)

почини прокси

почини прокси

Зачем ? Работает же он.

Ну вот для примера тащу wget-ом страницу - и норм.

через https

ок, уговорил, сноси

Других не вижу.)

composer запускать с -vvv пробовал?

composer запускать с -vvv пробовал?

нет. делаю composer diag и там вижу как застревает на https и вылетает по таймауту

юзеру порт недоступен

юзеру порт недоступен

доступен. потому что wget отрабатывает

всё же посмотри в selinux

Wget это клёво

но порт недоступен для бинарника php

доступен. потому что wget отрабатывает

странно, а curl работает?

странно, а curl работает?

Да))

Да))

с curl и http и https, оба порта работают?

ах ну да

Checking https connectivity to packagist: Downloading https://packagist.org/packages.json using proxy ssl://<ip_адрес>:порт

Вот на этой строке висит composer

ну с vvv надо запускать если этого еще не делается

ну с vvv надо запускать если этого еще не делается

Это с -vvv

разреши уже php стучаться в 443 порт

разреши уже php стучаться в 443 порт

Как ?

selinux

ERROR: S client not available

apparmor

https://getcomposer.org/doc/articles/troubleshooting.md#operation-timed-out-ipv6-issues-

там какая-то команда лечебная есть)

я не думаю, что у него v6 настроен

selinux

Так уже делал.

Через iptables тоже.

Так уже делал.

как - так?

iptables -I INPUT -p tcp -m tcp —dport 443 -j ACCEPT

причем тут фаервол?

semanage port -a -t http_port_t -p tcp 443

причем тут фаервол?

Да откуда знаю. Я всё открыл что можно было.

Схуяли только пхпэшный curl отказывается работать с прокси, если всё остальное нормально отрабатывает. Тут что-то другое я думаю.

Вобщем убунтопроблемы, развлекайся

Вобщем убунтопроблемы, развлекайся

курл не ходит из-за убунту? ахаха

больше походит на ограничение прав той же сети

видел такое на центосе кажется вроде селинукс

но я в эту магию прелдпочитаю не играть

1. попробуй консольный курл

2. попробуй fsockopen

ВОт это сработало только.

antiphp ник доставил

Надеюсь, Фолли не взорвется

Надеюсь, Фолли не взорвется

?

Как то ты быстро решил проблему, не настрадался поди

Как то ты быстро решил проблему, не настрадался поди

Я бы не сказал что быстро. Я с этой проблемой 6 часов возился.

хаюшки

йоу

йоу

йогогоу

здорово, Кострома :)

кек

здорово, Кострома :)

теперь будешь постоянно напоминать? в какой я глуши живу