Не работает curl centos
Обновлено: 07.07.2024
Я не могу найти подходящих пакетов для этого через yum или rpm . Есть ли стандартный способ сделать это обновление без установки из исходного кода?
Какую версию CENTOS вы используете? Мне лень проверять текущие версии ядра и номера версий CENTOS . Слишком ленивый или слишком крутой? (шучу) У нас работает 5.4, большую часть времени. Изредка 5.6. Есть ли заметная разница? ОП, не могли бы вы принять ответ? Лучший ответ успешно сработал для меня, и это будет полезно для будущих пользователейЭто старый вопрос, но он по-прежнему один из первых результатов поиска в Google, поэтому я хотел бы опубликовать решение, которое решило мою проблему.
1) создать новый файл /etc/yum.repos.d/city-fan.repo
2) Вставьте следующее содержимое:
Обратите внимание, что для других версий rhel / centos все, что вам нужно сделать, это указать соответствующий URL-адрес city-fan.
Подтверждая это (на моей версии Centos 6.5), это единственное, что сработало. Просто ввод yum update curl или yum install curl один не работает !! Должен ли я удалить city-fan.repo после обновления? Я читал, что это может вызвать проблемы при получении других неофициальных обновлений. Я попробовал это на последнем CentOS 7, и он работал отлично. (Использование этого репозитория было полупоследним средством. Сначала я попытался скомпилировать curl самостоятельно, но по умолчанию он не поддерживал SSL, а для компиляции с SSL требовалось большое количество зависимостей.)Зачем вам нужно обновить curl? Есть ли какая-то особенность, которую вам не хватает?
Вы можете получить это прямо от разработчика:
Прокрутите список до Redhat (спасибо twirrim), найдите подходящий RPM (на основе RHEL5) и установите.
Нам особенно нужна функция, представленная в 7.16.2, CURLOPT_TIMEOUT_MS для установки очень маленьких тайм-аутов. Мы пытаемся создавать запросы «запусти и забудь». Списки Fedora, которые мы попробовали, на самом деле являются исходными пакетами, с которыми мы не знакомы. Можете ли вы предоставить некоторую помощь / совет при обновлении через источник? Ха - ха. Спасибо twirrim, я перестал прокручивать в fedora. : - / В любом случае они выглядят как одни и те же пакеты, просто фильтровать по версии RHEL проще, чем эквивалентную версию FC.Не могу получить ответ Таксана на работу для моей настройки, вот что я использовал
Последняя стабильная версия curl - 7.22.0, но до сих пор 7.19.7-16 - последняя версия CentOS. Поэтому вам нужно либо найти репозиторий, который предлагает последнюю сборку, либо подождать, пока базовое хранилище CentOS обновит сборку.
Я нашел для вас репо:
Вы можете wget получить файлы libcurl и curls по ссылке выше, а затем rpm –Uvh packagename установить libcurl и затем пакет curls.
если я SSH на сервер как root & call
. Я получаю следующий ответ.
однако, если я вхожу в систему как любая из учетных записей cPanel (также используется при работе через веб-сервер), я получаю следующий.
Я не смог найти окончательного ответа на эту проблему, и моя хостинговая компания отказывается помочь, поскольку она "не поддерживает", хотя на прошлой неделе она работала нормально!
" если libcurl был построен с поддержкой NSS, то в зависимости от дистрибутива ОС, вероятно, необходимо предпринять некоторые дополнительные шаги для использования системы сертификации cert db. RedHat поставляется с дополнительным модулем libnsspem.Итак, что позволяет NSS для чтения пакета OpenSSL PEM CA. Эта библиотека отсутствует в OpenSuSE, и без него NSS может работать только со своими собственными внутренними форматами. NSS также имеет новый формат базы данных:https://wiki.mozilla.org/NSS_Shared_DB"
. но я не могу найти информацию о том, как я получить эту работу на моем CentOS в сервер.
если вы недавно достигли здесь, как я сделал при поиске той же ошибки напрасно, вы можете обнаружить, что это обновление для NSS вызывает сбой на CentOS. Проверьте, запустив обновление yum и посмотрите, получаете ли вы ошибки, curl также создает эту ошибку. Решение достаточно простое, просто установите NSS вручную.
если вы похожи на меня, он выбросил ошибку, похожую на эту:
это заняло некоторое время, чтобы решить, но обнаружил, что это не сертификат CA, потому что воссоздавая их и проверяя всю конфигурацию, я исключил это. Это мог быть libcurl, поэтому я пошел искать обновления.
следующий шаг (вероятно, должен был быть моим первым), чтобы проверить, что все было в курсе, просто запустив yum.
Это дало мне утвердительный ответ, что есть большая проблема в игре: Downloading Packages: error: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD Problem opening package nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm Я начал читать о проверке сертификатов с NSS и о том, как это новое обновление может быть связано с моими проблемами. Итак, ням сломан. Это потому, что НСС-softokn-* должен НСС-softokn-freebl-* нужны друг другу, чтобы функционировать. Проблема в том, что они не проверяют друг друга на совместимость, и в некоторых случаях это заканчивается разрывом yum. Пойдем исправим вещи:
попробуйте еще раз и успех!
оказывается, проблема заключалась в том, что скрипт запускался из cPanel "email piped to script", поэтому работал как пользователь, так что это была проблема пользователя, но не влиял на веб-сервер вообще.
причина, по которой пользователь не может получить доступ к каталогу /etc/pki, заключалась в том, что они только заключили в тюрьму ssh-доступ. Как только я предоставил полный доступ, все сработало отлично.
Спасибо за информацию, Реми.
убедитесь, что у вас установлены правильные права на пакет сертификатов CA. Обычно это означает доступ для чтения всех файлов CA в каталоге /etc/ssl/certs, например /etc/ssl/certs/ca-certificates.ЭЛТ.
вы можете увидеть, какие файлы были настроены для вас curl версии с
здесь вам нужен доступ для чтения к/etc/ssl/certs / ca-сертификатам.crt
и то же самое здесь.
ошибка вызвана повреждением или отсутствием файлов сертификатов цепочки SSL в каталоге PKI. Вам нужно будет убедиться, что файлы ca-bundle, следующие шаги: В консоли / терминале:
Теперь перезапустите службу: мой пример это команда:
очень большая хороший вид
заметил эту проблему, когда я неправильно настроил путь хранилища ключей. После исправления пути хранилища ключей он работал.
Команда, которую Вы нашли на SO - исключительно глупая, наверняка из контекста вырвали. Она не делает ничего. Вот просто ничего, создает копию файла и все. И портит его возможно.
Как заставить? Ну, подать нормальный сертификат, где ключ соответствует сертификату ;)
Но с этим же key.pem и cert.pem работало на обычном шаред хостинге (правда без nss).
Есть ещё набор файлов .p12, .der, .crt, .key. Из них нужно генерировать новые key и cert в .pem?
Я, откровенно, плох в этой теме, не приходилось сталкиваться, поэтому буду очень благодарен, если поможете.
Вот, сколько понимаю, у человека аналогичная проблема. Оттуда взял код
WotanWeb, ну, .p12 - это архив с ключом, сертификатом и сертификатом выпустившего CA. Должен быть, по крайней мере.
Из него можно достать составляющие (пароль от него должен у Вас быть):
Достаем сертификат
Достаем сертификат выпустившего СA
Достаем ключ. Ключ достается в две команды, в первой будет запрошен пароль для хранения ключа, пустой нельзя, но можно указать что угодно, все равно второй командой он снимается (если снимать пароль с ключа не надо, вторая не нужна)
Файл .der требуется только если софтина принимает только сертификаты в двоичном формате (такое бывает). Он получается из файла .crt следующей командой:
А где же здесь .pem? А расширение .pem фактически не означает ничего. То есть означает "это нечто, связанное с сертификатами". Я обычно так называю сертификаты (без ключа) у которых кроме обычной части есть еще текстовая, читаемая людьми (и игнорируемая автоматами)
Если я подключусь к серверу по SSH как root и позвоню
. я получаю следующий ответ .
Однако, если я вхожу в систему под любой из учетных записей cPanel (также используемых при работе через веб-сервер), я получаю следующее .
Я не смог найти окончательного ответа на проблему, и моя хостинговая компания отказывается помочь, так как она «не поддерживает», хотя на прошлой неделе она работала нормально!
"Если libcurl был собран с поддержкой NSS, то, в зависимости от дистрибутива ОС, возможно, потребуется предпринять некоторые дополнительные шаги для использования общесистемного центра сертификации. сертификат db. RedHat поставляется с дополнительным модулем libnsspem.so, который позволяет NSS для чтения пакета OpenSSL PEM CA. Эта библиотека отсутствует в OpenSuSE, и без него NSS может работать только со своими внутренними форматами. NSS также имеет новый формат базы данных: https://wiki.mozilla.org/NSS_Shared_DB "
. но я не могу найти информации о том, как я могу получить эту рабочую систему на моем сервере CentOS.
Информация
Оказывается, проблема заключалась в том, что скрипт запускался из cPanel, «отправляемого по электронной почте в скрипт», поэтому он был запущен от имени пользователя, поэтому это была проблема пользователя, но не влияла на веб-сервер вообще.
Причина того, что пользователь не может получить доступ к каталогу / etc / pki, была связана с тем, что он имел только заблокированный доступ по ssh. Как только я предоставил полный доступ, все заработало.
Спасибо за информацию, Реми.
У меня была аналогичная проблема с ошибкой № 77 на CentOS7. Мне не хватало softlink /etc/pki/tls/certs/ca-bundle.crt , установленного с RPM ca-сертификатов.
Curl пытался открыть этот путь, чтобы получить центры сертификации. Я обнаружил с помощью:
И ясно увидел, что по этой ссылке не удалось открыть.
Мое исправление было:
Это должно снова настроить все. Если у вас есть частные центры сертификации для корпоративного или самозаверяющего использования, убедитесь, что они находятся в / etc / pki / ca-trust / source / anchors, чтобы их можно было повторно добавить.
Если вы недавно попали сюда, как я, тщетно пытаясь найти ту же ошибку, вы можете обнаружить, что это обновление для NSS, вызывающее сбой в CentOS. Протестируйте, запустив yum update и посмотрите, есть ли ошибки, curl также создает эту ошибку. Решение достаточно простое, просто установите NSS вручную.
Если вы похожи на меня, он выдал ошибку, подобную этой:
Это заняло некоторое время, чтобы решить эту проблему, но оказалось, что это не сертификат CA, потому что, воссоздав их и проверив всю конфигурацию, я исключил его. Это мог быть libcurl, поэтому я отправился на поиски обновлений.
Следующим шагом (вероятно, должен был быть моим первым) было проверить, все ли обновлено, просто запустив yum.
Это дало мне утвердительный ответ, что в игре есть более серьезная проблема: Downloading Packages: error: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD Problem opening package nss-softokn-freebl-3.14.3–19.el6_6.x86_64.rpm Я начал читать о проверке сертификатов с помощью NSS и о том, как это новое обновление может быть связано с моими проблемами. Итак, конфетка сломана. Это потому, что nss-softokn- * нужны nss-softokn-freebl- * нужны друг другу для работы. Проблема в том, что они не проверяют совместимость версий друг друга, и в некоторых случаях это приводит к нарушению yum. Пойдем исправим:
Читайте также: